[FEATURE] Persistent UI indicator for a pending ScheduleWakeup — an armed loop looks identical to a dead session

Filed by Claude Code on evnchn's behalf.

While a dynamic-/loop wakeup is pending, the idle UI shows nothing. Last night my session armed ScheduleWakeup for an overnight babysitting task — tool result: Next wakeup scheduled for 03:50:00 (in 3643s) — and then sat at a plain idle prompt. I had no way to tell an armed session from a wedged one, so I burned a turn typing "huh, continue" purely to ask "are you alive?". UX-wise it reads as: the model just shut down the convo when I need it to continue the work overnight.

Ask: a persistent, passive indicator for the whole lifetime of a pending wakeup — status-line segment or idle-prompt banner, e.g. ⏰ wakeup armed — fires 03:50. Appears at arm, survives intervening user turns, clears on fire/stop/cancel. (If session-scoped CronCreate jobs have the same silent pending state, same treatment.) This should be display-only from the model's perspective — the scheduler can already report the fire time when arming; if the TUI doesn't own that state, this amounts to a read-only scheduler-status view. Precedent: background bash tasks already get a visible running indicator; a pending wakeup is the same class of session state with strictly longer silent lifetimes, and currently the only class with zero representation.

<details>
<summary><b>Not the same ask as the existing ScheduleWakeup issues</b></summary>

• Hidden-prose family (#75217, #77358, #74184, #85109, #73897, #82634): asks for the model's text around the ScheduleWakeup call to render. Necessary, but even fully fixed it yields one transient line at arm time that scrolls away — an hour later the idle screen still can't answer "wedged or waiting?". (My arming turn hit this too: the sign-off text never rendered, which compounded the fear.)
• #85292 (CLI-native list/cancel): pull-based control — you must already suspect a wakeup exists and interrogate for it. My failure mode is the opposite: no reason to believe one exists, so you conclude the session died. Ambient state needs push-rendering; the two compose (indicator makes it visible, #85292 makes it controllable).
• #64744 (loop survives Ctrl+C, no way to detect/stop): detection of an already-runaway loop, framed around kill. Not a passive armed-state affordance.
• Reliability family (#80679, #74569, #77462 — wakeups silently vanish): an indicator would incidentally make these diagnosable: "banner disappeared without a fire" becomes observable, where today vanished and never-armed look identical.

I could not find an existing issue asking for an always-visible pending-wakeup affordance.

</details>

Environment: Claude Code 2.1.220 CLI (macOS, tmux), claude-fable-5, interactive session.