Observations captured during a provider quota cooldown are lost if the worker restarts before the cooldown ends

**What happens** When the five-hour quota guard trips (`quota:five_hour utilization 95.0% >= 95%`), the worker skips the generator for every new session: ``` [WARN ] [SESSION] [session-2105] Skipping generator start while the provider quota cooldown is active {source=init, provider=claude, window=five_hour, ...} ``` The PostToolUse observations are still enqueued, but into `SessionMessageBuffer`, which is in RAM by design ("this buffer deliberately holds work only for the worker process lifetime ... If the worker dies, the buffer is gone and recovery is a transcript replay"). The cooldown can last for hours: on one day the log has 5,704 "Skipping generator start" lines. If the worker restarts in that window (a plugin update, a crash, a reboot, or a launchd/systemd restart), every buffered message is dropped (I found no log line about the dropped messages), and nothing replays them afterwards. **Measured on one machine** - 3 sessions on 2026-09-25 (37 prompts) ran entirely inside a cooldown, and the worker restarted the same day. - Their 91 tool calls are all in `tool_uses`, with input and response, and `observation_id` NULL on every row. The sessions have no observations and no `memory_session_id`, 12 days later. - Across the whole database, 16 sessions have `tool_uses` rows but no observations. ```sql SELECT session_db_id, count(*), sum(observation_id IS NULL) FROM tool_uses WHERE session_db_id IN (2105, 2106, 2109) GROUP BY 1; -- 2105 | 41 | 41 -- 2106 | 22 | 22 -- 2109 | 28 | 28 ``` A side effect: these sessions never get a `memory_session_id`, so on other devices their prompts arrive with `memory_session_id: null` (see #4571). **Why it matters** The loss is silent, and the trigger (a quota cooldown) is exactly when a long session is most likely, because the user is working heavily. The durable record needed for recovery already exists: `tool_uses` (v51) keeps the raw tool I/O, and the transcript JSONL is still on disk. **Possible directions** 1. On startup, and when a cooldown ends, re-feed `tool_uses` rows that have `observation_id IS NULL` for sessions that never produced observations, in their original order. `tool_uses` is already durable and deduplicated by `(content_session_id, tool_use_id)`, so this avoids the old durable-queue retry storm. 2. At minimum, log a warning with a count when a non-empty buffer is dropped at shutdown, so the loss is visible.