fix(#4079): forbid ScheduleWakeup wake-tool escape hatch at background-wait sites (#4299)

* test(#4079): guard every background-wait site against ScheduleWakeup wake-tool escape hatch

Content-contract tests over plan-phase.md, stall-detection-helpers.md, and
manager.md: every wait-instruction site must forbid ScheduleWakeup (the
host /loop tool whose partial-args call surfaces the red validation error
in #4079), while the sanctioned wait mechanisms stay byte-preserved.

* fix(#4079): forbid ScheduleWakeup wake-tool escape hatch at every background-wait site

The orchestrator could literalize 'I'll wait' by calling the host's
ScheduleWakeup tool (/loop pacing surface) with partial arguments while a
background subagent was in flight, surfacing the red validation error
'`prompt` is required when `stop` is not true.' GSD never sanctioned a
wake call; now every wait-instruction site says so explicitly: the two
synchronous stop-and-wait ORCHESTRATOR RULEs in plan-phase.md, the
stall-detection-helpers.md fragment (loaded before every gsd_stall_watch
wait), and both manager.md background-dispatch rules. The sanctioned wait
mechanisms (blocking Agent() return, gsd_stall_watch polling, dashboard
loop) are unchanged. The regression test uses the shared
readFileNormalized helper (code-review finding).

Emitted-Drift-Ack-Growth: plan-phase.md — #4079 guard sentence at the two stop-and-wait rules (+396 B, within the phase6 shrink-only line)
Emitted-Drift-Ack-Growth: manager.md — #4079 guard sentence at both background-dispatch rules

* chore(#4079): add changeset fragment (pr placeholder, backfilled after PR open)

* chore(#4079): backfill PR number in changeset

---------

Co-authored-by: sim <sim@local>

gsd-core/workflows/plan-phase/steps/stall-detection-helpers.md

@@ -48,6 +48,15 @@ min), real, bounded call that reliably hands control back — the outer
 threshold is enforced by `dispatch_ts` accumulating across calls, not by one
 call's own duration.
 
+**Never a wake-up call between cycles (#4079):** while the orchestrator waits
+between `gsd_stall_watch` cycles, it must NOT call `ScheduleWakeup` (or any
+host wake/sleep-scheduling tool, e.g. the `/loop` pacing surface) to
+literalize "I'll wait". The `gsd_stall_watch` bash call IS the wait mechanism;
+wake-up scheduling is never part of it, and a partial-args `ScheduleWakeup`
+call surfaces the host's red validation error (`prompt` is required when
+`stop` is not true). Just issue the next watch call (or let the blocking
+Agent() return) — nothing else.
+
 **Disclosed tradeoff:** the first cycle always sleeps a full
 `PLANNER_STALL_INTERVAL_MINUTES` before its first check, so a planner that
 completes in seconds is not observed by this path until that interval