Marks GAP-15 resolved and records the three wrong-over-cap-count defects the
tracker-lifecycle batch closed, with why they had to precede the revocation
batch: decision A1 removes the self-healing that limits the damage of a miscount.
Notes why the v3 identity split had not yet caused visible harm -- fresh v3
starts sent no owner attribution at all, so the transport record landed under
user 0, which the enforcer skips, silently exempting the stream from the cap
rather than double-counting it. That is a worse failure than the double count it
masked, and worth recording so the next reader does not "fix" only the visible
half.
Corrects the "fully async monitoring" claim instead of rushing the queue: the
first Redis projection write per session is synchronous so the record is visible
before the request returns, and later liveness and byte updates ride the refresh
tick. The consequence -- a slow Redis adds latency to the first request of a
stream -- is now stated. The ordered, lifecycle-aware projection queue is
deliberately deferred until its startup, drain, cleanup ordering, backpressure
and refresh interaction can be designed together; a naive fire-and-forget
projection is exactly what caused the ghost-session defect this batch fixed.
Follow-up list renumbered accordingly; the GAP-14 (A7) and opMu items are
retained, not dropped.
Part of #305.
CoffeeKnyte
b1502d70f5