AFI parity: generate the matrix from conformance probes, not prose

The per-adapter parity table was hand-maintained prose. An adapter that
never wired a capability (FastAPI SSR, Axum WebSocket) got its gap
relabelled "Django-only" or "out of scope — use native equivalents," and
nothing went red. The de-scope was crystallized in five mutually-ratifying
sites: the README §Stack-extensions table, the AFI fixture docstring
("channels/forms/shapes aren't AFI-common"), the core registry's
extension-hook framing, the mizan-fastapi __init__ docstring, and a
"CSRF is Django-only" comment in two adapters' session endpoints.

Replace prose-parity with conformance-generated parity:

- tests/afi/manifest.py declares the AFI-common surface as data — one list
  of capabilities, one of adapters. Applicability ("—") is derived from
  transport, never typed.
- tests/afi/probes.py independently inspects each backend's source for the
  artifact a capability requires (comment-stripped, backend-scoped). Green
  means wired; a cell can't be set by editing a word.
- tests/afi/test_capability_parity.py asserts every (capability × applicable
  adapter) pair is wired. 35 unwired gaps are now loud red TFDD tests, each
  naming an owed binding. No xfail/skip.
- tests/afi/parity_table.py generates the README table from the probes;
  `make parity-check` fails CI on any hand-edit, like the codegen byte-parity.

Purge the five de-scope sites. The IR byte-parity gate is unchanged and green.
`make test-afi` is now intentionally red on the 35 gaps — that board is the
owed parity work, itemized; a gap turns green by being wired, never described.

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

cores/mizan-python/src/mizan_core/registry.py

@@ -1,12 +1,16 @@
 """
 Mizan core registry — function and composition registration with an
-extension hook for backend-specific registries (channels, forms, etc.)
-to plug into.
+extension hook for the AFI-common capabilities that need their own
+sub-registry (channels/WebSocket, forms, shapes) to plug into.
 
-This is the framework-agnostic registry. Backends own their own
-type-specific registries (channels in Django Channels, forms in Django
-Forms, websockets in FastAPI, etc.) and register them as extensions
-here so the unified schema export can include them.
+This is the framework-agnostic registry. The extension points
+(channels, forms, websockets, shapes) are AFI-common: every adapter owes
+a binding for each, and registers it here so the unified schema export
+sees it. Django binds all of them today; the other adapters' unbound
+extensions are gaps tracked by the capability-parity suite in
+`tests/afi/`, not framework-specific features. The binding is per-stack
+(Django Channels vs. native WebSocket, Django Forms vs. Pydantic); the
+capability is common.
 """
 
 from __future__ import annotations