feat(spawn): boot-process presence sentinel independent of the ready sentinel

[Masashi-Ono0611]

Fixes #455

Summary

The boot script spawn.sh generates now writes its own pid to run/boot-pid.<team>__<agent> right before exec'ing the role's CLI, and clears it right after -- on normal return, and via a trap on HUP/TERM/INT for abrupt termination (SIGKILL still leaves it for the next kill(pid,0) liveness check to invalidate, same contract as every other sentinel in this codebase).

This is a liveness signal independent of the existing ready.<team>__<agent> sentinel, which only appears once the CLI/model reaches its own watcher-registration step. Some agent types (grok-build) start their watcher only when the model follows the actas template's instructions (ADR 0003); when the very first model turn itself fails -- e.g. an unresolved rate/usage-limit dialog the CLI presents instead of continuing -- that step is never reached, and an external liveness check has no way to tell "launched and still running, registration incomplete" apart from "nothing was ever launched, or it already exited."

Scoped to spawn.sh's boot-script launch path only, per #455's discussion; resurrect-panes.sh's tmux-send-keys relaunch (after a server restart) has no boot-script process of its own to carry a pid file, so it's out of scope for this particular fix.

Test plan

• Reviewed with Codex (self multi-model review, bounded codex exec) -- 1 Warning addressed (HUP/TERM/INT trap), 2 Suggestions reviewed and left as consistent with existing repo conventions.
• 65/65 tests/test_spawn.bats pass, plus a new test covering the sentinel.
• No regressions in resurrect-panes.bats / actas-lock.bats.
• CI green on ubuntu/macos/windows.
• Dogfooded live: a downstream consumer (a Claude Code SessionStart hook that auto-recovers a grok-build peer) uses this sentinel today to distinguish "already booting, don't spawn a duplicate window" from "genuinely dead, recover" -- directly motivated by hitting exactly the scenario in grok-build: liveness check has no way to tell 'CLI alive but stuck before watcher registration' from 'dead' #455 (Grok Build CLI stuck at a weekly-usage-limit dialog before its watcher ever registers).

[Masashi-Ono0611]

Duplicate of #456, which you already opened on 2026-07-20 for the same issue (#455) with additional history (a Codex-review-driven follow-up commit for HUP/TERM/INT trap cleanup that this PR's single squashed commit also includes, just without that separate commit trail). Closing this one in favor of #456 -- apologies for the duplicate, I should have checked for an existing open PR before opening a new one from the same fork branch, not just checked for an existing issue.