tri: stranded-work finder and cron tick resume card #5786

Problem

Two things a cron loop needs at the top of every tick are read by hand today:

1. Stranded work. On 2026-10-04 a tick found by accident that trinity's feat/queen-browser-embedded held 2 owner-approved commits, pushed 2026-09-29, merging clean into main, with no pull request -- four days with nothing reporting it. No command lists remote branches that have unique commits, are older than N hours, and have no open PR.
2. Resuming a tick. A tick starts cold from cron_tracking/<id>/tick-state.json and ledger.md (LOOP-RULES R0) plus the worktrees the state names. The fact that matters most -- did the previous tick die mid-work? -- is a join of claim age and a dirty tree, and nobody does that join by eye.

Proposal

Two read-only helpers under scripts/tri_loop/, stdlib only, --json, exit codes stated, each printing what it does NOT establish:

• tri stranded [PATH...] [--repo-path PATH] [--hours 24] -- no fetch (refs as of the last fetch, said so); default from refs/remotes/origin/HEAD; open PR heads from gh pr list (if gh fails: "PR state unknown", nothing called stranded); skips dependabot/*, patch-equivalent branches (git cherry) and branches whose content is already on the default (squash merges); reports ahead/behind, last commit, and whether git merge-tree --write-tree merges clean -- with merge-tree pointed at a throwaway object directory so nothing is written.
• tri tick [--id ID] -- the resume card: topic, tick, claim and its age, last ledger ## section, per-worktree exists / branch / dirty / ahead-behind vs base / last commit age, and anomalies with a one-line fix each (stale claim + dirty tree, worktree missing, branch mismatch, base unknown, state unparseable, ledger tick != state tick). Exit 0/1/2. Never writes; git runs with GIT_OPTIONAL_LOCKS=0.

Each gets a self-test in scripts/ci/ run by loop-tools-gate, with a negative control.