RFC: Cargo-like manifest schema with WIT refs, registry, and BLAKE3 lock

[joshuajbouw]

Replaces the v0.5 Capsule.toml topic surfaces with one Cargo-shaped declaration. Solves four problems that surfaced during the wasmtime migration:

1. Three places declare topics today ([[topic]] / [capabilities].ipc_* / [[interceptor]]). Drift between them is silent and the parser tolerates partial declarations.
2. [[topic]].direction is serde-required without a default — every capsule manifest on main that omits it fails to install on a fresh checkout. Five chat-stack capsules carry local "add direction" patches.
3. [[topic]].description is capsule-author-controlled prose that reaches LLM context in some pipelines — a structural prompt-injection vector.
4. Topic schemas (wit_type) are optional and rarely populated — most cross-capsule topics travel as untyped JSON.

This RFC introduces:

• [publish] / [subscribe] tables — one entry per topic, required wit = "@scope/repo/iface/record" reference, handler = "..." binds to #[astrid::interceptor("...")] exports.
• Flat [exports] / [imports] with quoted "<namespace>:<interface>" keys.
• [[tool]] description_for_llm — the only capsule-author-controlled string that reaches the LLM, operator-reviewed verbatim at install.
• Capsule.lock pinning resolved git SHAs + BLAKE3 content hashes for reproducible installs.
• Lightweight git-backed registry (unicity-astrid/registry — one TOML per published package) with semver resolution + direct-ref escape hatches (rev / tag / branch / path).
• wit = \"opaque\" for legitimate heterogeneous-wildcard uplink/proxy capsules.

Replaces / supersedes

This RFC overlaps the surface of #20 (capsule interface system). #20 documented the v0.5 `[exports]` / `[imports]` design; this RFC supersedes that surface and extends to the topic / lockfile / registry layers. If both land, #20 should be closed in favour of this one (or rebased to document the v0.5 history only).

In-flight implementation pieces (referenced; not part of this RFC)

• WIT records for every cross-capsule topic landed in unicity-astrid/wit#2: 7 new packages + 4 extended.
• Capsule manifests in this format are prepared on `migrate/cargo-manifest` branches in each `unicity-astrid/capsule-*` repo. Held until the kernel parser supports the new schema.
• Kernel parser rewrite to support this schema is the implementation entry point and not yet started.

Verification done

• Per-file syntax validation of every WIT record this RFC depends on (16 interfaces, all clean under `wasm-tools component wit`).
• Cross-package reference resolution verified by grep against declaring packages.
• Single-package bundle of all 16 interfaces (intra-package `use` form) parses cleanly.
• One non-imports/exports capsule (memory) installed cleanly with the new manifest format under the current parser — confirms the new top-level sections (`[publish]`, `[subscribe]`) are silently tolerated, while the new flat `[imports]` form fails parser type checking (`invalid type: string '^1.0', expected a map`). Both behaviours are expected and explicitly covered in the migration step.

Reading order

The RFC document under `text/0000-cargo-like-manifest.md` is structured per the repo template:

1. Summary — one paragraph.
2. Motivation — six concrete problems with the v0.5 surface.
3. Guide-level explanation — what a capsule manifest looks like, what the operator sees on install, what gets resolved through the registry, what `Capsule.lock` does.
4. Reference-level explanation — full schema, resolver algorithm, registry index format, validation rules, CLI surface, migration path.
5. Drawbacks, Rationale and alternatives, Prior art, Unresolved questions, Future possibilities.

Discussion notes

Threads worth surfacing on this PR rather than burying in a tracking issue:

• BLAKE3 vs SHA-256 (the wider Rust supply-chain ecosystem uses SHA-256 — pushback expected).
• Whether `[[tool]].description_for_llm` should have a length cap.
• Trust model on the registry (compromise of a maintainer's GitHub account allows malicious publishes — open in "Future possibilities").
• Heterogeneous wildcards: `wit = "opaque"` chosen over `wit = ["a", "b"]` for honesty over enumerable typing — alternatives discussed in §Rationale.