Guard per-keeper SSE applies against a mid-event stop
The consumer loop read `started_flag` once at the top of each
iteration, then ran three separate lock-protected applies
(tree_keeper → workspace_keeper → inbox_keeper) against the same
event. If `stopSseConsumer` flipped the flag while the consumer was
awaiting any of those locks — and `wipeState` spawned its own task
to drain them — a final event could slot in *after* the drain and
re-inhabit the keepers with outgoing-session material.
Re-check the flag inside each apply step, *after* the relevant
keeper lock has been acquired. On a mid-event stop the consumer
bails instead of mutating drained state; the wipe task's drain then
races safely against nothing. Both orderings (consumer-wins-lock /
wipe-wins-lock) are now symmetric: the loser checks the flag and
returns.
Thread `started_flag` into `apply_keyring_to_workspace_keeper` and
`apply_grant_to_inbox_keeper` so they can perform the check-then-
act under their own lock. Inline the equivalent guard for the
tree_keeper apply in the main loop.