ADR: define portable bindings over the Rust core

[flyingrobots]

Outcome

Define one stable foreign binding contract for Node.js, Bun, Deno, and future consumers without forking Keep identity, formats, verification, durability, or recovery semantics by runtime.

Dependencies

• Stable native handles and receipts from this milestone
• Implement precise verification reports and corruption refusal #20 precise verification reports
• Prove the Graft Golden File Worldline end to end #24 integration evidence

Decision questions

• Which C ABI, N-API, WebAssembly, or generated binding boundary preserves typed failures and bounded streaming most faithfully?
• Which operations may be synchronous, blocking worker calls, or streaming callbacks?
• How are cancellation, backpressure, process death, and secret-bearing buffers represented?
• Which runtime-specific crypto or filesystem adapters are forbidden because they would fork native semantics?
• How are version and feature compatibility negotiated?

Acceptance criteria

• A numbered ADR chooses the binding architecture and explicitly rejects semantic forks.
• Identity and durable-format bytes come only from the Rust core.
• Typed failure distinctions survive every binding.
• Large inputs and outputs remain bounded and streaming.
• Cancellation cannot upgrade partial output into a successful receipt.
• Secret-bearing buffers have an explicit lifetime and logging policy.
• One conformance suite runs against every supported runtime adapter.
• Node.js, Bun, and Deno support claims require live executable witnesses, not API-shape inference.

Non-goals

• Reimplementing Keep in JavaScript or TypeScript.
• Runtime-specific content identity.
• Requiring a subprocess in the storage path.
• Shipping bindings before the native contracts stabilize.