Populate passive capability-registry revision 1

[joshuajbouw]

Problem

#1234 adds the content-addressed registry primitives and freezes the 51 exact
revision 1 IDs, but it intentionally does not populate their authorization
semantics. Later enforcement needs one passive manifest with fixed scope, target
kinds, delegability, privileged status, source, and canonical digests.

Scope

• build the 51-entry kernel revision defined by RFC: content-addressed authority profiles rfcs#36
• preserve the current display catalog's scope and danger metadata
• assign Extreme display danger to the six registered additions outside the current catalog
• freeze all 51 BLAKE3 entry digests and the aggregate registry-revision digest
• require every kernel/admin capability mapping to resolve to a registry entry
• complete the request-variant inventories used by the drift gates
• classify every revision 1 ID as primary, secondary, token-authenticated, dormant, or mapping-only

Non-goals

• no evaluator activation
• no wildcard migration or persisted-state changes
• no profile assignment or delegation-entry generation
• no socket, HTTP, IPC, WIT, or public wire changes

Acceptance criteria

• the passive manifest contains exactly the 51 normative IDs with kernel provenance
• catalog scope and danger values cannot drift from their registered definitions
• golden entry and manifest vectors match the canonical BLAKE3 encoding
• every revision 1 ID has exactly one current enforcement-role classification
• the raw revision ID set remains private
• core and kernel tests, formatting, clippy, MSRV, wasm portability, public API compatibility, and repository CI pass

Depends on #1233 and #1234. Tracks #1228.