fix: Unit 6 — convention + doc cleanup (C-09, C-20-rem, C-22-rem, C-24, P-10, P-11)

Conventions satisfied, `cargo doc` clean, no actively-wrong comments,
producer/consumer naming consistent in the call/registry docs.

P-10 — `pump_sink` matched the string literals "call.published",
"call.completed", "call.aborted" (dispatch.rs) instead of the
EVENT_PUBLISHED / EVENT_COMPLETED / EVENT_ABORTED constants the rest
of the file imports. Replaced with the constants — pure refactor
hazard, no behavior change.

C-20 remainder — the wrong "SAFETY:" comment at from_call.rs:271
marked no `unsafe` block and was factually wrong (described a `'static`
return that isn't what `derive_alpn_from_op_name` does — it returns
`Option<String>`; the leak happens in `leak_alpn`). Reworded to a
plain note about the `'static` lifetime requirement. Also reworded
the abort-cancels claims in the `pump_sink` and `pump_stream` doc
comments (dispatch.rs): both claimed `call.aborted` "cancels the task
and drops the handler future" — the handler is actually `join!`-ed to
completion and not yet cancelled (the abort-cancels-Pub mechanism is
review 001 Unit 9). Trimmed step-numbered narration comments in
adapter.rs / client.rs that restated what the code does, keeping the
ordering-constraint and REQ-CH comments. The big reassembly.rs
deliberation landed with Unit 4; this finishes the remainder.

C-09 — fixed the 2 remaining `cargo doc` warnings (was 4; the
register_openable links were fixed in Unit 3):
- `unresolved link to default_policy` (operations.rs:50) — the
  [`default_policy`] intra-doc link resolves to
  super::policy::default_policy; used the full path.
- `env is both a module and a macro` (channels/mod.rs:30) — the
  [`env`] link collided with the std `env!` macro; qualified as
  [`self::env`].
`cargo doc --no-deps` now emits 0 warnings.

C-22 remainder — removed the filler `PhantomData` test at client.rs
(`let _ = std::marker::PhantomData::<ChannelClient>;` — asserts
nothing). The env.rs tautology was already removed in Unit 3.

C-24 — replaced "client→server streaming" with "producer→consumer
streaming" in call-protocol.md, operation-registry.md, README.md, and
open-questions.md (4 occurrences). Per AGENTS.md §8 the convention is
producer/consumer, not server/client. The remaining "client→server"
references in channels ADRs 034/037 are in stream_type table contexts
that Unit 10 (C-26) will handle as part of the spec-doc renumbering.

P-11 — amended ADR-046 §3's SinkHandler type so the stream item type
matches §6. §3 declared `Pin<Box<dyn Stream<Item = Value> + Send>>`;
§6 declared `Pin<Box<dyn Stream<Item = Result<Value, CallError>> +
Send>>`. The code uses §6's shape uniformly (registration.rs:32-40,
aliased as PublishStream). §3's text and the Door-type section are
amended to match §6; the Door-type section already marked the concrete
stream item type a two-way-door detail, so this is a text correction,
not a design change. Added an amendment note dated 2026-08-13.

Verification:
- cargo test --lib         → 449 passed, 0 failed (was 450; -1 removed filler test)
- cargo clippy --all-targets -- -D warnings → clean
- cargo fmt --check        → clean
- cargo doc --no-deps      → 0 warnings (was 2)

src/protocol/dispatch.rs

@@ -403,11 +403,11 @@ impl Dispatcher {
     /// ends after it and we do NOT write `call.completed` (ADR-049 §6).
     ///
     /// If a frame write fails the pump stops early; the stream is dropped on
-    /// return, releasing the handler's resources via `Drop` (ADR-016). The
-    /// pump is cancellable: it runs inside the `handle_stream` task, so a
-    /// `call.aborted` for this request ID (handled by `handle_abort` on
-    /// another stream) or connection close cancels the task and drops the
-    /// stream.
+    /// return, releasing the handler's resources via `Drop` (ADR-016). A
+    /// `call.aborted` for this request ID mutates the `PendingRequestMap`
+    /// (via `handle_abort` on another stream) but does not yet cancel this
+    /// task — the pump ends when the stream ends naturally or the I/O fails
+    /// (the abort-cancels mechanism for Sub/Pub is review 001 Unit 9).
     pub(crate) async fn pump_stream<W: tokio::io::AsyncWrite + Unpin>(
         &self,
         writer: &mut super::wire::FrameFramedWriter<W>,
@@ -440,10 +440,10 @@ impl Dispatcher {
     /// is written to the wire as `call.responded` (or `call.error`).
     ///
     /// The handler runs concurrently — it consumes the
-    /// `PublishStream` while we feed it. `call.aborted` for this request
-    /// ID (handled by `handle_abort` on another stream) or connection
-    /// close cancels the task and drops the handler future, releasing
-    /// the handler's resources via `Drop` (ADR-020).
+    /// `PublishStream` while we feed it. On `call.aborted` for this
+    /// request ID, the feed injects an `Err` into `chunk_tx` and ends;
+    /// the handler future is awaited to completion (it is not yet
+    /// cancelled — the abort-cancels-Pub mechanism is review 001 Unit 9).
     pub(crate) async fn pump_sink<R, W>(
         &self,
         reader: &mut super::wire::FrameFramedReader<R>,
@@ -472,7 +472,7 @@ impl Dispatcher {
                             continue;
                         }
                         match envelope.r#type.as_str() {
-                            "call.published" => {
+                            EVENT_PUBLISHED => {
                                 let chunk = envelope
                                     .payload
                                     .get("input")
@@ -482,8 +482,8 @@ impl Dispatcher {
                                     break;
                                 }
                             }
-                            "call.completed" => break,
-                            "call.aborted" => {
+                            EVENT_COMPLETED => break,
+                            EVENT_ABORTED => {
                                 let _ = chunk_tx
                                     .send(Err(CallError::internal("publish aborted by initiator")))
                                     .await;