Answer the rate-limit menu while WAITING; ignore rolled-forward stale banners

[amanjaiman]

Summary

Fixes the daybreak-1 failure where the watchdog never answered Claude's "What do you want to do?" rate-limit menu and then detached right at reset time.

• WAITING now scans for auto-responses. Only RUNNING and LIMITED ran scanAutoResponses, so a menu that drew a tick after the limit banner (the supervisor moves LIMITED → WAITING within one poll) sat unanswered for the whole wait and swallowed the resume prompt.
• RESUMING ignores stale rolled-forward banners. A bare-clock banner from the event just waited out, worded differently from the line that latched, re-parsed after the reset as tomorrow's time — a 24h wait that exceeded max_wait and detached the watchdog. The re-hit check now applies the same IsNextDayRollForward guard onRunning already used.

From the actual run log:

00:20:54 usage limit detected
00:20:57 reset at Sat 03:10 EDT ... waiting 2h50m3s
03:11:03 injected resume prompt (attempt 1): "Limit has been reset. Continue."
03:11:06 resume re-hit the limit (cycle 1); re-waiting
03:11:09 reset at Sun 03:10 EDT ... beyond max_wait — detaching

Tests

• TestAutoResponseAnswersMenuThatAppearsWhileWaiting — menu draws during WAITING, asserts 1\r is injected and the wait continues.
• TestResumingIgnoresRolledForwardStaleBanner — post-reset banner resolving to tomorrow's time confirms the resume instead of re-waiting.

Both reproduce the log sequence above and fail without their fixes. go build ./... and go test ./... pass.

🤖 Generated with Claude Code