fix(grok-build): bind fresh grok watchers + reap dead-grok orphans (#245)

[fujibee]

Problem

Grok Build's monitor tool launches the agmsg watcher with an empty
$GROK_SESSION_ID. Two failure modes followed:

1. Lingering orphan watchers. An empty session id fell back to a bare
   throwaway instance id. The watch.sh: self-exit when owning CC session is no longer alive #67 liveness guard only applies to composite
   ids (<sid>.<pid>), so a bare-id watcher never self-exits when its grok
   session dies — it lingers indefinitely (observed: a watcher still alive
   3h+ after its grok had exited). A prior fix bound a composite id only for
   grok --resume <id> sessions (id present in argv); a fresh grok (no
   --resume) still fell back to bare.

2. Silent message loss. If the watcher's stdout consumer truncates the
   stream (e.g. a | head -5 appended to the monitor command), writes past
   the consumer's close are dropped while the watermark advances past them,
   so later messages are lost silently.

Fix

• agmsg_grok_instance_id (generalizes the former resume-only helper):
  resolves a composite <session_id>.<grok_pid> for both grok --resume and
  a fresh grok. For a fresh grok it binds to the grok process that is the
  watcher's ancestor, paired with the project's newest session id. Composite
  ids are stable across watcher relaunches (no watermark/replay gap) and
  liveness-gated, so the watcher self-exits when grok dies.
• agmsg_reap_orphan_grok_watchers: on startup a fresh grok watcher reaps
  leftover bare-id grok-build watchers whose grok has already exited.
  Specific-PID kill only; a strict invocation match (watch.sh must be the
  executed program, with grok-build and the project as positional args)
  ensures a process that merely mentions those strings is never killed.
• grok-build monitor rule + onboarding template: instruct agents to pass the
  monitor command exactly, with no | head / | tail / pipe / redirection
  appended (a closed downstream pipe drops messages silently).

Tests

New regression tests (bats):

• composite resolution for resume and fresh grok; newest-session-dir; grok
  ancestor resolution
• watcher-arg matching incl. false-positive exclusion (a shell that merely
  mentions the strings is not matched)
• reaper safety (no-op / self-safe when nothing matches)
• an 8-message burst delivered with no loss

All changed suites green locally (test_instance_id.bats, test_watch.bats).

Verification (local machine)

• Composite resolution against a live grok session yields <id>.<pid>
  (liveness-gated on the grok pid).
• Reaper dry-run: keeps a watcher whose grok is alive, flags only watchers
  whose grok has exited.
• Before/after for the loss path: with | head -5, only 5 of 8 messages were
  delivered; without it, all 8 were delivered.

Closes #245.

Update: monitor-mode launch hardening

Live dogfooding surfaced that the silent "messages never arrive" reports (and
accumulating watcher tasks) were caused by the launch method, not the watcher:
the grok-build rule described delivery as "a background watcher you launch with
the monitor tool", and the word "background" led agents to start watch.sh
via run_terminal_command with background: true. That logs the stream to a
file and never injects it into the conversation — a silent failure. (The
emit/watermark print logic is unchanged; the session-binding work in this PR did
not cause it.)

This adds launch-method hardening to the grok-build delivery rule and onboarding
template:

• delivery is described as coming from the monitor tool (drops the
  "background watcher" framing)
• explicit prohibition: launch with the monitor tool only — never
  run_terminal_command (with or without background: true), and never a
  hand-rolled tail -f of a log
• a verify step: confirm a live monitor task named agmsg inbox stream exists
  after launch, and relaunch via the tool if it is missing