procs: claim each codex rollout once when pairing

[yrstm]

Defect

Codex pairing resolved per process with no claim tracking (unlike PairClaude). Two codex resumes of one session — both processes holding the same rollout open, or two starts inside the same ±300s window — rendered as identical clone rows (same task/tokens/ctx) and double-counted the session in the header tallies. Observed live: pids 586010/1514979, both /code/synth, one rollout, two confident rows.

Fix

New procs.PairCodex batch pass mirroring PairClaude's claimed map:

1. fd tier — newest process wins a shared-rollout tie; the losing process is a second attach to a known session, so it stays unpaired outright (exact evidence names its session — falling through to a timestamp match would fabricate a different one; a test pins this with a decoy rollout).
2. meta tier — start-time match against unclaimed rollouts only.

Unpaired processes surface through the existing +N unmatched footer / -a, never as clone rows. Collect feeds both the scan pass and row pass from the one map, as before. No --json shape change.

Evidence

• TestPairCodexClaimsARolloutOnce stages the exact observed state (two pids, one held rollout, plus the decoy); TestPairCodexMetaTierClaimsOnce covers the timestamp tier.
• Live A/B on the devbox: by the time the patched build ran, the two processes had moved to different rollouts, so old and new binaries agree on today's board — the unit tests are the repro, labeled as such.
• Local gates: go test ./... -race green, go vet clean, golangci-lint run 0 issues, linux+darwin builds compile.

🤖 Generated with Claude Code