RFC 0002: expand extern host ABI to decision-ready proposal

[proofmancer]

Same treatment as #70 did for RFC 0001 (memory model): pushes RFC 0002 (extern host ABI) from "strawman with 7 open questions" to "specific proposal with 2 open questions and a concrete implementation roadmap."

What changed

Added sections

• Summary: one-paragraph TL;DR
• Hard constraints: 5 invariants every host function must satisfy (determinism, gas metering, bounded execution, no state mutation, chain-layer trust)
• Recommended approach expanded with:
  • Declaration syntax in real Cleave
  • Calling convention examples (verify_signed_transfer using keccak256 + ec_recover)
  • Full marshaling ABI table for primitives, slices, fixed arrays, Results
  • Chain manifest `host_extensions:` integration (uses Grammar: open subsystem keys to arbitrary identifiers #64 generic subsystem keys)
  • Namespace-prefix versioning rationale (`host_v1.blake3` vs SHA-of-implementation)
  • Concrete gas-pricing table shape (fixed + per-byte)
  • Trust model with stdlib / custom distinction
• Full lifecycle example: stdlib declares blake3, module imports it, chain authorizes it, runtime validates at load, another chain rejects the same module for missing the authorization
• Initial stdlib host function set: 7 functions (blake3, sha256, keccak256, ec_recover, bls12_381_pairing, bls12_381_aggregate, ed25519_verify) with Rust crate sources
• Counterargument section addressing: "just compile crypto to WASM," "allow arbitrary user host fns," "why not Component Model," "reentrancy ban kills useful patterns"
• Migration path: no impact on existing examples; compiler adds parsing + lowering; runtime adds registration + validation
• 5-phase implementation roadmap totaling ~830 LoC compiler + runtime + ~300 LoC stdlib impls + ~150 LoC byte-level ABI spec:
  • 5a: Grammar + parsing
  • 5b: Type checker integration
  • 5c: Codegen import lowering
  • 5d: Runtime registration + chain manifest
  • 5e: Gas pricing + bench
• Decision criteria so the RFC has a clear bar for graduating from draft to accepted

Resolutions to open questions (7 -> 2)

Question	Resolution
Allow-list scope	decided: per-chain via manifest
Versioning	decided: namespace-prefix (`host_v1.*`)
Determinism enforcement	decided: stdlib audited, custom is operator's problem
Gas accounting	decided: fixed per-call + per-byte, charged before execution
Type marshaling	decided: detailed table, full byte-level ABI in `spec/abi/extern-host.md`
Trust model	decided: stdlib blessed, no community registry for custom
Composition / reentrancy	decided: forbidden, host fns are pure compute only
Stdlib build flags	OPEN: minimal vs full runtime build
VRF / random source	OPEN: out of scope for v1, likely v2 addition

Why now

RFC 0001 (memory model) reached decision-ready form in #70 and is awaiting review. RFC 0002 was the obvious follow-up since:

• 0001 explicitly delegates the escape-hatch mechanism to 0002 ("the only way out of the safe-language envelope")
• 0002's existing strawman was the thinnest of the four open RFCs
• The implementation phase is small (Phase 5 of the RFC 0001 roadmap, ~830 LoC) so committing to specifics makes the work tractable
• The chain manifest grammar change (Grammar: open subsystem keys to arbitrary identifiers #64) lifted the parser-layer restriction that this RFC's `host_extensions:` key needed; no preceding implementation work blocks RFC 0002 acceptance

What this PR does NOT do

• Not a decision. Stays in `draft` status. The decision criteria spell out what it takes to move to `accepted`.
• Not implementation. Phase 5 work cannot start until RFC 0001 phases 1-4 are at least partially landed (memory model needs to support `Result<T, E>` etc. before extern host functions can declare them as return types).
• Not the byte-level ABI document. The RFC commits to the framework (small primitives as i32/i64, slices as ptr+len, fixed arrays via memory pointers); a separate `spec/abi/extern-host.md` will detail the bit-exact encoding when Phase 5c lands.

What unblocks next

Once accepted: Phase 5 implementation can start independently of Phases 1-4 if we're willing to ship extern host without memory model support for non-primitive return types. Most stdlib host functions return `[u8; 32]` or other fixed arrays that the v0 grammar already accepts.

The position paper (#67) gains a concrete extern-host story to cite. Existing chains (none today) would not be affected by either RFC since they have no `extern host` calls.