fix(364): gate multiply-instantiated support to verified MultiMemory + fix SR-31 traceability

[avrabe]

Fixes #364 — SR-31 "multiply-instantiated detection" was marked verified
via an isolated reject test while #362 wired the normalization
unconditionally, making the reject dead code on the live path and the shipped
behavior (accept) the opposite of the certified property. Thanks @avrabe for the
sharp catch.

Root cause (confirmed)

expand_multiply_instantiated_modules was wired unconditionally into
fuse_with_stats, so DuplicateModuleInstantiation never fires on the live
(instantiate $m) path, while ls_m_5_multiply_instantiated_module_rejected
verifies it in isolation. The inc-3 execution oracle only covered MultiMemory
(independent memories); under SharedMemory the instances share one linear
memory and independence is unverified (reproduced: the 2nd instance collapses to
a single bump export, not bump+bump$0).

Fix (avrabe's option b, honestly)

• lib.rs — gate the normalization to explicit MultiMemory, the only
  strategy the execution oracle proves keeps per-instance state independent.
  Under SharedMemory (unverified) and Auto (implicit, ADR-4) the
  normalization is skipped → the DuplicateModuleInstantiation reject fires. So
  shipped behavior == verified behavior.
• multiply_instantiated_runtime.rs —
  shared_memory_and_auto_reject_multiply_instantiated proves the reject fires
  on the live fuse path under both strategies.
• Traceability repointed to live-path evidence (not the isolated reject):
  docs/verification-matrix.md SR-31 row, sw-verifications.yaml SWV-31,
  safety-requirements.yaml SR-31 verification-description + SR-55 scope note.

MultiMemory support (SR-55) is unchanged and still execution-verified (independent
globals + memory + data segments). Per-instance import wiring stays noted as
un-execution-tested (import-free fixtures).

Verification

Full meld-core suite green (0 failures); fmt + clippy clean; rivet validate
PASS.

Closes #364.

[github-actions]

LS-N verification gate

✅ 59/59 approved LS entries verified

	count
Passed (≥1 test, all green)	59
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.}