docs(multi-memory): publish stable MultiMemory lowering contract (#300)

[avrabe]

Why

synth (synth#404) committed to building its model-2 lowering — carry memidx through the IR, distinct native bases, explicit cross-memory ops (synth#369), per-memory base/size export — against meld's MultiMemory output as the stable target, staged behind its "frozen-fixture re-freeze + differential oracle" discipline.

But that target was never published: the contract lived only implicitly in meld-core/tests/multi_memory.rs, the source, and scattered #300 prose. You can't freeze a differential oracle against an unwritten contract — every meld output churn would silently invalidate synth's fixtures.

This publishes docs/multi-memory-lowering-contract.md as the citable, frozen model-2 lowering target.

Contract (C1–C6, all grounded in code/tests, cited inline)

• C1 N memories preserved 1:1, no collapse — multi_memory.rs N=2 and N=3 tests
• C2 deterministic per-memory→component identity via export naming (name${comp_idx} on collision, merger.rs:1992) — the relation an embedder uses to assign MPU/PMP regions
• C3 authoritative memory_index_map relation (merger.rs:95)
• C4 cross-memory memory.copy/memory.fill emitted with explicit distinct memidx, never dropped (rewriter.rs:423 remap asserts src 1→8/dst 0→2; p3_bridge.rs stream shims; result-copy adapter) — the shape synth#369 must lower instead of loud-skipping
• C5 per-memory size rides in the memory section; native base is synth's
• C6 --memory multi + --address-rebase is a hard error (lib.rs:2913) — rebasing is the shared-collapse path, mutually exclusive with structural isolation

Change policy

C1–C6 are frozen as the model-2 lowering target (meld#300 / ADR-4). A change is a contract change announced on #300 with a synth heads-up; synth files against meld if it hits a MultiMemory structure it cannot consume (per synth#404).

Docs-only; no code change. Refs #300, synth#404, synth#369, gale#86.

🤖 Generated with Claude Code

[github-actions]

LS-N verification gate

✅ 57/57 approved LS entries verified

	count
Passed (≥1 test, all green)	57
Failed (≥1 test failure)	0
Missing (no ls_*_NN_* test found)	0

_{Approved loss-scenarios.yaml entries are expected to have a
regression test named ls_<letter>_<num>_* (e.g. LS-A-11 →
ls_a_11_*). The gate runs each prefix via cargo test --lib --no-fail-fast and aggregates pass/fail/missing.}

Failed LS entries

(none)

Missing regression tests

(none)

_{Updated automatically by tools/post_verification_comment.py.
Source of truth: safety/stpa/loss-scenarios.yaml.}