feat(bin): confirm tmux submits from semantic lifecycle records

[JaredHuynhning]

Finishes the semantic-lifecycle migration on the tmux submit path (system-review item 1): an instruction's delivery is confirmed from the harness's own lifecycle signal, with rendered-composer scraping demoted to an explicitly labelled fallback.

What changed

• Confirmation requires positive evidence. Only a record-proven idle baseline enters the semantic path, and a send is confirmed (empty turn-opened) only when a trusted busy record with an advanced sequence is observed after an Enter keystroke the send actually delivered. An unchanged record never confirms anything: busy, unknown, malformed, and stale baselines - including the spawn-time seed and a stuck record from a crashed turn - route to the rendered-composer core, whose verdict carries an explicit composer-fallback label.
• A rejected keystroke is a failure. If every Enter keystroke fails, the verdict is send-failed, never a confirmation.
• The rendered signal can veto, never grant. With FM_SUBMIT_SEMANTIC_COMPARE=1 (the bake-in default) the composer is read exactly once, after the verdict; a confirmation contradicted by a still-pending composer is downgraded to unknown semantic-contradicted, and every disagreement is recorded durably in state/<id>.submit-disagreement (cleaned by teardown, documented in AGENTS.md). fm-send accepts only exact empty, so a pending-reply delivery is never committed on a contradiction - closing the suppression class behind the 9.5-hour incident recorded in bin/fm-tmux-lib.sh's header.
• Coverage: claude, opencode, pi, and pi-signed confirm semantically through the existing feat(bin): replace busy heuristics with semantic lifecycle state #1327 hook, plugin, and extension wiring. Codex, kimi, grok, unarmed tasks, and context-free sends (the away-mode daemon) keep the scraper; the daemon's call shape and verdicts are byte-identical. Eligibility reads bin/fm-busy-lib.sh's trust table, so codex and kimi flip automatically when their verification gates open.
• The confirm-window floor (FM_SUBMIT_SEMANTIC_MIN_BUDGET) defaults to a conservative 2 seconds per attempt, sized to cover the writer chain (harness event dispatch, process spawn, writer lock, atomic write) on a loaded machine.

Known gaps, deliberately not addressed here

• No send-to-turn correlation. Confirmation is an observed idle-to-busy transition, not a correlated acknowledgement, so an unrelated turn that opens in the confirmation window can be credited to a send when the composer reads empty or unknown. The bake-in comparison only vetoes the case where the composer still shows the text.
• No concurrent-send serialisation. Two concurrent sends to one task can read the same idle baseline and both claim the same turn. A per-task lock built in an earlier round was removed by explicit decision: it half-covered the problem (busy and ineligible sends bypassed it) while adding failure modes of its own.
• Both gaps are owned by the queued fm-submit-correlation follow-up, which starts from the premise that this needs a per-submit token the harness echoes back, not more shell-side inference.
• The live hook-write latency measurement is deliberately not taken here. The 2-second floor is sized to cover the unmeasured writer chain conservatively rather than tuned to a measurement; a too-short budget reports a delivered send as unconfirmed (loud), never the reverse.

Validation

Validated through the no-mistakes pipeline: two review rounds (three findings fixed in-pipeline: the test suite registered in the runner's family map, a stale lock comment removed, and the confirm-budget rationale corrected with the raised floor), full test suite, documentation, and lint all green. tests/fm-tmux-submit-semantic.test.sh proves transition-confirmed submits with zero pane reads at the post-bake-in setting and exactly one post-verdict read at the default, the contradiction downgrade with its durable record, the rejected-Enter refusal, and that busy baselines never confirm from the record.

🤖 Generated with Claude Code