docs: streams upgraded to in-scope (operator-authority record)

The inventory graded streams absent because no paused consumer document
names it; the operator correction: type-filtered event watching from
several places (e.g. repo-change subscriptions in a git app at
gitea/gitlab scale) is a basic reactivity requirement — and notify
(fire-and-forget, no replay) cannot serve subscriptions honestly.
The wanters are applications above the paused crates, which is why the
docs don't carry the row.

Inventory: streams row recorded on operator authority (the REQ-2
recording convention from alkblobs requirements.md), confidence system
gains the operator-authority grade; rate-limits becomes the sole
first-cut candidate. phase-0: OQ-ST-01 summary and OQ-ST-04's
contract-candidates updated to match.

docs/research/phase-0.md

@@ -2,7 +2,8 @@
 status: draft
 last_updated: 2026-10-04 (consumer inventory landed — OQ-ST-01 answered
 per-feature from the paused consumers' documents; OQ-ST-02/07
-sharpened; phase-0 plan step 1 done. Interface finding and driver
+sharpened; phase-0 plan step 1 done; streams upgraded to in-scope by
+operator-authority record same day. Interface finding and driver
 tension from 2026-10-03 remain trusted-but-unverified working input.)
 ---
 
@@ -320,7 +321,12 @@ OQ-FS-05 writer coordination); queues and the outbox helper are
 documented needs (alkfs sync/fetch-on-miss outbox; alkblobs
 embedder-owned maintenance cadence); the scheduler is documented-thin
 (the family-wide "who sweeps/renews/reaps" problem, possibly collapsing
-into queues); streams, rate limits, and result storage have **no
+into queues); streams was upgraded by an operator-authority record
+(the 2026-10-04 correction to the inventory's initial read:
+type-filtered event watching from several places — repo-change
+subscriptions in a git app, cross-app event watching — a reactivity
+requirement notify cannot serve honestly, being fire-and-forget);
+rate limits and result storage have **no
 named consumer** — carried per the keep-until-implementation posture
 with cut-flags visible, cut later rather than silently included.
 
@@ -387,11 +393,12 @@ point — the question decomposes into contract-pinning rather than
 shape-invention:
 
 - Which parts of the honker-rs surface become the crate's *contract*:
-  the `notify`/`listen` pair, the queue claim/ack/visibility model,
-  locks, outbox, scheduler — all now have named consumers (inventory);
-  the stream/offset/consumer model does not (streams is keep-with-flag)
-  and rate-limits have an in-crate alternative mechanism (alkgit's wire
-  layer) — subset, renamed/regrouped, decided against the inventory
+  the `notify`/`listen` pair, the stream/offset/consumer model (in
+  scope per the inventory — subscriptions are the durable reactivity
+  half notify can't serve), the queue claim/ack/visibility model,
+  locks, outbox, scheduler — all have named consumers now; rate-limits
+  have an in-crate alternative mechanism (alkgit's wire layer) —
+  subset, renamed/regrouped, decided against the inventory
   rows rather than against the whole honker menu.
 - What is the delivery-guarantee contract, per mechanism (honker's
   own guide table shows how easily per-binding auto-checkpoint vs