fix(schedule): close review gaps

docs/subsystems/persistence.md

@@ -10,6 +10,8 @@ The seam is a textbook [capability seam](../../.agents/notes/implemented/archite
 
 `session/event` is a *synchronous* notification; persistence plugins copy the event into a per-session controller without blocking the producer. The first pending event starts a fixed batching window, and later events join without resetting its deadline. Expiry starts one durable batch; events admitted during that write receive their own deadline and form a follow-up batch. `session/flush` cancels the wait and drains through quiescence, so the loop still uses it as the ordering and error-observation checkpoint before claiming the next ordinary turn. A rejected background write retains its events and pauses automatic retry; a new event starts a fresh window, while explicit flush retries immediately and reports failure through `agent/error` and the logger, never as a session event past the closed turn. Disposal performs the same final drain. The configured maximum bounds only intentional batching wait, not event-loop scheduling or backend durability latency ([decision](../../.agents/notes/implemented/architecture/2026-08-08-bounded-session-persistence-write-batching.md)).
 
+A `session/flush` listener returns literal `true` only after completing durability work; observe-only listeners return void. Once every listener settles, `SessionStore.flush()` returns `true` and publishes contained `session/flushed(session, throughSeq)` only when at least one listener acknowledged durability and none failed. `throughSeq` is the exclusive event boundary captured at call entry, so events appended during the checkpoint require a later success; concurrent checkpoints may publish boundaries out of order. An empty or observe-only checkpoint returns `false`, and a rejection publishes no success observation.
+
 ## Crash recovery preserves an interrupted turn
 
 A backend that reloads a log crashed mid-turn finds an open `turn/start` with no `turn/end`. It does **not** truncate — a single turn can be huge in a long-horizon task (many steps, large tool output), and those events were durably appended before the crash. Instead it closes the orphaned turn with a synthetic `turn/end { reason: { kind: 'interrupted' } }`, keeping the interrupted execution balanced without changing any standalone events before or after it. `interrupted` is the one `TurnEndReason` no loop emits (see [session.md](session.md#why-a-turn-ended-turnendreasonmap)).