fix: Unit 3 — register_openable + per-connection ChannelCore (C-02, C-03, C-09)

A channel-open op could not be registered or invoked (C-02):
ChannelCore::register_openable did not exist, and resolve_channel_manager
(C-03) was a stub returning None — the ADR-047 §4 dynamic-resolution
shape (downcast context.env to &dyn ChannelOperationEnv) was unworkable
as written: context.env is a PeerCompositeEnv, not a single concrete
type that can be downcast to a channels-backed env.

The fix is per-connection registration (ADR-047 §4 amendment,
2026-08-13): a ChannelCore is constructed per channels connection (in
the install_channel_zero hook, which already runs per-connection and
already receives the ChannelManager), and register_openable is called on
that connection's overlay OperationRegistry (Layer 2 per ADR-019). The
wrapper closes over the per-connection ChannelCore and uses
ChannelCore::manager() directly — no context.env downcast. This
preserves every invariant ADR-047 §4 was written to protect (layering,
per-connection resolution) without adding as_any() to OperationEnv
(which would close the session/connection overlay patterns from
ADR-024, AGENTS.md §6).

Changes:
- ChannelCore::register_openable wraps the ALPN's OpenHandler with the
  ACL→check_open→open_channel→spawn→respond flow (ADR-047 §3). Branches
  on spec.op_type: Query/Mutation→Once, Sub→Stream (emits { channel_id }
  and completes; data plane on the channel's BiStream), Pub→Sink (stub:
  channel:pub_open_not_implemented — requires the channel-adoption path,
  C-08/Unit 5). The OpenHandler receives (input, Connection, AuthContext)
  and spawns the ALPN's protocol on the channel's BiStream, returning a
  JoinHandle for teardown.
- ChannelManager::set_handler_task installs the spawned OpenHandler's
  JoinHandle after open_channel (which allocates the channel first to
  get the BiStream halves, then the handler is spawned, then the task is
  recorded for abort on channel/close / connection drop).
- channel:too_many_channels / channel:allocation_failed error codes
  mapped to CallError with details (channel:forbidden is the ACL's
  FORBIDDEN, already handled by the registry before the wrapper).
- resolve_channel_manager stub removed (C-03); ChannelOperationEnv trait
  and ChannelsSessionEnv retained as a two-way-door implementation detail
  for future per-connection routing (not on the open-op path). The
  tautology filler test (C-22 env.rs) removed.
- ADR-047 §4 amendment records the per-connection-registration decision
  (two-way door: the ADR's door-type section explicitly marks the wrapper
  shape as a two-way-door implementation detail; the one-way decisions
  — per-ALPN op names, channel_open marker, removal of channel/open —
  are unchanged).

Acceptance gate (C-02/C-03): one end-to-end test wires ChannelClient ↔
ChannelsAdapter over a real tokio::io::duplex carrying the channels
8-byte chunk header wire format. The accept side's install_channel_zero
hook builds a per-connection ChannelCore, registers a no-op open op
(channels/tty/sub) via register_openable, and runs the dispatch loop.
The client calls call_open_op("channels/tty/sub") on channel 0; the
wrapper does check_open→open_channel→spawn→respond. Asserts the
response carries a non-zero channel_id and that the per-identity quota
was reserved (policy count for the caller incremented to 1).

Verification: 438 tests pass (was 437; +1 e2e), clippy clean, fmt clean,
doc warnings 2 (was 4; fixed the 2 register_openable broken-link
warnings — C-09; the remaining default_policy and env module/macro
warnings are Unit 6 long-tail items).

docs/architecture/decisions/047-openable-alpns-are-operations.md

@@ -2,7 +2,89 @@
 
 ## Status
 
-Accepted (amends ADR-037; refines ADR-044, ADR-046)
+Accepted (amends ADR-037; refines ADR-044, ADR-046; §4 amended
+2026-08-13 — open ops are registered per-connection, not resolved via
+`context.env` downcast — see "Amendment (§4 per-connection
+registration, 2026-08-13)" below)
+
+## Amendment (§4 per-connection registration, 2026-08-13)
+
+ADR-047 §4 specified that the open-op wrapper resolves the
+per-connection `ChannelManager` by downcasting `context.env` to
+`&dyn ChannelOperationEnv` at invocation time — "static registration,
+dynamic resolution." Implementation (review 001, C-03) found this
+shape is not workable as written: `context.env` is a `PeerCompositeEnv`
+(a composite of base + session + per-connection overlays), not a single
+concrete type, so a direct `as_any()` downcast of `context.env` to
+`ChannelsSessionEnv` cannot reach the `ChannelManager`. Traversing the
+composite's layers to find the channels-backed overlay would hardcode
+`PeerCompositeEnv`'s internal structure into the channels module —
+fragile, leaky, and a layering violation (the call crate's composite-env
+shape is not part of the channels crate's contract).
+
+**The amendment: open ops are registered per-connection.** The
+`ChannelCore` is constructed per channels connection (in the
+`install_channel_zero` hook, which already runs per-connection and
+already receives the `ChannelManager`). `ChannelCore::register_openable`
+is called on that connection's `OperationRegistry` (the connection
+overlay registry, Layer 2 per ADR-019), closing over the per-connection
+`ChannelCore`. The wrapper uses `ChannelCore::manager()` directly — no
+`context.env` downcast, no dynamic resolution. The open op lives on the
+connection overlay, which is where per-connection state naturally
+belongs (ADR-019, ADR-024).
+
+This preserves every invariant ADR-047 §4 was written to protect:
+
+- **Layering (ADR-044):** the call crate stays free of channels types.
+  The open-op wrapper is in `channels-call` (`src/channels/operations.rs`);
+  the call crate's `OperationRegistry` and `OperationEnv` are unchanged.
+  No `as_any()` is added to `OperationEnv` (the trait stays concrete-rpc-
+  shaped, preserving the session/connection overlay patterns from
+  ADR-024 — AGENTS.md §6).
+- **Per-connection resolution:** the open op gets the *right*
+  `ChannelManager` (the one for the connection it was invoked on) because
+  the op is registered on that connection's overlay registry, with a
+  `ChannelCore` closing over that connection's manager. A globally-
+  registered handler (Layer 0) is not on this path.
+- **"Marked ops invoked outside a channels session" (ADR-047 §2):**
+  unchanged. A `channels/<alpn>/sub` op registered only on a channels
+  connection's overlay is not reachable on a bare `alknet/call`
+  connection (the overlay isn't attached there) — the dispatch path
+  returns `NOT_FOUND`, which is the correct behavior for "no channels
+  session" (the `channel:no_channels_session` error code from the
+  original §4 is no longer reached; `NOT_FOUND` is the natural
+  reachable-but-not-here result).
+
+The `ChannelOperationEnv` extension trait and `ChannelsSessionEnv` impl
+(`src/channels/env.rs`) are retained as a two-way-door implementation
+detail — they are not on the open-op path, but remain available for
+future per-connection routing (e.g., nested channels where each
+connection's overlay carries its own manager reference for
+non-open-op queries). The `resolve_channel_manager` stub is removed
+(it described the rejected dynamic-resolution shape).
+
+### Door type
+
+**Two-way (implementation detail).** The ADR's door-type section
+already marks "The `ChannelCore` wrapper shape, the extension-trait
+pattern, and the opener ledger are two-way-door implementation details
+within the one-way decision." Per-connection registration vs. dynamic
+resolution is a choice within the wrapper-shape detail — the one-way
+decisions (per-ALPN op names, the `channel_open` marker, removal of
+`channel/open`/`direction`) are unchanged. A future revision could move
+open ops back to Layer 0 with real `as_any()` downcast machinery if the
+composite-env structure stabilizes enough to make the traversal
+non-fragile; the per-connection shape is the simpler choice today.
+
+### References
+
+- C-02, C-03 in `docs/reviews/001-pub-and-channels-integration-review.md`
+  (the `register_openable`-does-not-exist and
+  `resolve_channel_manager`-is-a-stub findings this amendment resolves)
+- ADR-019: operation registry layering (the connection overlay the open
+  op is registered on)
+- ADR-024: peer-graph routing model (the `OperationEnv` integration-point
+  pattern this amendment preserves by NOT adding `as_any()`)
 
 ## Context
 
@@ -186,6 +268,19 @@ architectural point is the wrapper.
 
 ### 4. Per-connection `ChannelManager` resolution (Gap E)
 
+> **Amended 2026-08-13** — see "Amendment (§4 per-connection
+> registration, 2026-08-13)" at the top of this file. The
+> dynamic-resolution shape described below (downcast `context.env` to
+> `&dyn ChannelOperationEnv` at invocation time) was found
+> unworkable as written (`context.env` is a `PeerCompositeEnv`, not a
+> single concrete type; the downcast cannot reach the manager without
+> fragile cross-layer traversal). The operative decision is
+> **per-connection registration**: `register_openable` is called on the
+> connection overlay registry (Layer 2), closing over a per-connection
+> `ChannelCore`; the wrapper uses `ChannelCore::manager()` directly.
+> The body below is the **original** (rejected) shape, retained for
+> rationale continuity.
+
 The `register_openable` helper registers ops at assembly time (Layer 0,
 curated, static per ADR-019). But the wrapper needs the
 **per-connection** `ChannelManager` — the op arrives on channel 0 of one