A channel's message slots are named from the client, on every backend

The IR called them react-message and django-message, so a FastAPI channel had
to declare a DjangoMessage. They are client-message and server-message now,
and the direction words hold wherever a channel is declared: Params /
ClientMessage / ServerMessage, with mizan-core deriving <Pascal>Params and
friends so no backend names a type itself. Django's ReactChannel and
FastAPI's ReactChannel are both Channel.

mizan-fastapi never registered a channels extension, so build_ir() emitted no
channel at all and every payload type was invisible to codegen. It registers
one now. RegistryExtension is an ABC requiring all(), which is what the IR
reads — an extension that cannot enumerate its registrations no longer exists.

The gate that should have caught the rename could not: tests/afi registered no
channel because mizan-rust had no channel registry to register one in, so a
five-package rename of the wire contract passed byte-parity without a channel
byte crossing it. mizan-rust grows ChannelSlotKind, a CHANNELS slice, a
#[mizan::channel] macro, and KDL emission whose wire_to_pascal matches Python's
split; the AFI fixture now carries a channel with every slot and one with a
single slot, so all three backends prove the contract byte for byte.

MizanChannel held three Option<String> beside three has_*() predicates and
unwrapped them with defaults; it holds an ordered slot vector, so an absent
slot is absent rather than defaulted. The channels target emitted a React
hooks file that a stage1-only consumer could not compile — react emits that
now. The codegen's parity tests byte-compared emitted source against baselines
without ever compiling it: they compile the generated crate and run its tests,
import the generated Python package and call every method, and typecheck each
TypeScript target against a consumer.

Also fixed at source: app_visitor printed its import diagnostic to stdout, the
stream export_mizan_ir writes KDL to, so a failed import silently corrupted the
IR; the apps root was hardcoded to "apps"; _default_literal crashed build_ir on
any non-JSON-serializable field default; Django and mizan-core derived Pascal
names two different ways, disagreeing on every dotted channel name.

ir.py builds a document and renders templates/ir/document.kdl.j2 rather than
appending KDL strings with hand-tracked indentation, and named types resolve to
a fixed point — a model reachable only through a union branch was referenced by
a ref that no type block ever defined.

The rest is the write-gate's own classifiers run over the standing tree:
relative imports, silent swallows, Protocol contracts that should be ABCs,
emitters hand-rendering target source, catch-all arms over closed enums, and
comments narrating the project rather than the code.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

frontends/mizan-webview-transport/src/index.ts

@@ -1,42 +1,8 @@
-/**
- * @mizan/webview-transport — routes Mizan calls through a VSCode webview's
- * postMessage channel instead of HTTP fetch or Tauri IPC. Paired with the
- * extension-host-side Mizan dispatcher (e.g. `MizanHost` in the holomorphic
- * extension), which receives envelopes via `webview.onDidReceiveMessage`
- * and posts responses back via `webview.postMessage`.
- *
- * Usage (webview side, inside the bundled React/TS app):
- *
- *   import { configure } from '@mizan/base'
- *   import { webviewTransport } from '@mizan/webview-transport'
- *
- *   configure({ transport: webviewTransport() })
- *
- * The transport keeps the same protocol surface as the HTTP and Tauri
- * transports (call/fetch envelopes, {result, invalidate, merge} response
- * shape), so the codegen output and React adapter are unchanged — only
- * the wire channel differs.
- *
- * Envelope shapes (this side ↔ extension-host):
- *
- *   webview → host:
- *     { kind: 'call',  id, fn, args }
- *     { kind: 'fetch', id, context, params? }
- *
- *   host → webview:
- *     { kind: 'response', id, ok: true,  body }
- *     { kind: 'response', id, ok: false, error: { status, body } }
- *
- * Correlation by `id` lets multiple in-flight calls share the one
- * postMessage channel.
- */
-
 import { MizanError, type MizanCallResponse, type MizanTransport } from '@mizan/base'
 
-// VSCode's webview API — present at runtime, declared globally so the
-// transport can be authored without pulling vscode types into a generic
-// frontend package. Returned by acquireVsCodeApi() exactly once per
-// webview load; subsequent calls throw.
+// acquireVsCodeApi is injected into the webview page by VSCode itself, so it is
+// declared here rather than imported. It returns the API object exactly once per
+// webview load; a second call throws.
 declare global {
     function acquireVsCodeApi(): VsCodeApi
 }
@@ -79,6 +45,8 @@ const pending = new Map<string, Pending>()
 let installed = false
 let counter = 0
 
+// One page-level message listener demultiplexes every response by envelope id,
+// since all in-flight calls share the single postMessage channel.
 function install(): void {
     if (installed) return
     installed = true
@@ -111,14 +79,7 @@ function send<T>(env: Envelope): Promise<T> {
     })
 }
 
-/**
- * Build a Mizan transport that routes through a VSCode webview's
- * postMessage channel. Install via:
- *
- *   import { configure } from '@mizan/base'
- *   import { webviewTransport } from '@mizan/webview-transport'
- *   configure({ transport: webviewTransport() })
- */
+/** A MizanTransport whose wire channel is the VSCode webview's postMessage pair. */
 export function webviewTransport(): MizanTransport {
     return {
         async call(fn, args): Promise<MizanCallResponse> {