Read daemon-owned rollouts for hand-typed Codex

[onevcat]

Stacked on #839. Review and merge #839 first; this PR's diff is only the detection change.

Problem

CodexLogProvider finds Codex rollouts through the open files of the pane's TUI process. A Codex 0.157+ TUI typed by hand attaches to the shared app-server daemon, which owns every rollout, so the TUI holds none. The state machine reported screen.noLiveTurn and relied on the screen alone. That is how the original symptom surfaced: a 0.158 footer change hid the Working row (#838), and nothing else knew the turn was open.

Change

• When the TUI's open-file inventory is complete and holds no rollout, the provider asks CodexDaemonThreadMapper (from Resolve CLI callers under Codex's shared daemon #839) for the pane's binding: the root thread of the pane's newest indexed submit plus every descendant the daemon holds open. It feeds those rollouts into the existing incremental decoder, so lineage, subagent work, and suspension rules are unchanged.
• The session log must belong to the current TUI process (header within 120 s after the process start), so a log left by an earlier TUI cannot bind.
• A newly bound rollout starts at the live task_started that precedes the bound submit, not at the file end. Binding happens only after the turn's user item lands, which is after task_started; starting at the end would miss the open turn of a resumed, older rollout.
• The rollout index honors the live boundary of forked rollouts. Measured on 0.158: /fork writes only the fork's own items, and a forked subagent copies task_started but not user items before its thread_settings_applied.
• The daemon is found through daemon.pid under the TUI's own CODEX_HOME, and the pid must still be the managed daemon.
• Embedded Codex (Profile launches, --no-daemon) is unchanged: its TUI owns its rollouts and is read directly.
• Docs: docs/components/agent-detection.md and docs-ai/073-codex-daemon-caller-identity/002-daemon-log-detection.md.

Verification

• New tests: binding family and live offsets, pending submit keeps the previous binding, index turn offsets, forked live boundary, stale session log rejection, provider live-offset start, provider daemon fallback wiring, and daemon.pid validation.
• make check, make test (3599 passed, 0 failed in supacode-tests), and make build-app pass.
• Live acceptance in a Debug instance on a dedicated socket, isolated CODEX_HOME daemon, two hand-typed Codex panes in one cwd (prowl agents --json, sampled every 2 s):

Scenario	detection_reason
Before the first submit	screen.noLiveTurn (unbound, as before)
Concurrent sleep 40 / sleep 15 turns	each log.openWork, then log.turnEnded at its own end
Subagent running sleep 20 while the parent waits	log.openWork throughout
/new, then a new turn	log.openWork on the new thread
Steered message during a turn	log.openWork throughout
Restart with codex resume of a thread created before the provider, then a turn	log.openWork
Esc interrupt	log.turnEnded