feat(adr7): multiply-instantiated module support — RFC-46 Q1 (path-H inc 3)

[avrabe]

Executes ADR-7 path-H, increment 3 — RFC-46 Q1 multiply-instantiated
modules, the "duplicate" resolution, execution-verified end-to-end. The
user's stated RFC-46 priority.

What changed

meld previously rejected a component that instantiates the same core module
more than once (SR-31 → DuplicateModuleInstantiation). It now supports it.

• core_instance_topology::expand_multiply_instantiated_modules — a
  pre-resolve normalization that, for each 2nd..Nth instantiation of a core
  module, appends a deep clone (a fresh module_idx) and rewrites the
  instantiation to the clone. After the pass no module is instantiated more
  than once.
• lib.rs — the pass is wired into Fuser::fuse_with_stats before
  resolve/merge (with an info log of how many modules were duplicated).

Why it's correct — it reuses a proof

The merger's index-remapping is already proven correct for N distinct
modules. Turning "module M instantiated N times" into "N distinct modules"
means each instance gets independent functions/memory/tables/globals — no
shared mutable state (H-1) — and every (component, module)-keyed merge map
gets a distinct key per instance, so the whole class of duplication-overwrite
bugs (segment_bases, realloc_map, resource maps, mutable globals) an index-space
audit enumerated simply cannot arise.

Differential execution oracle (the gate)

tests/multiply_instantiated_runtime.rs::two_instances_keep_independent_counter_state
— a component instantiating one core module (a mutable counter) twice is
fused (MultiMemory, CoreModule), validated, and executed on wasmtime. The two
instances' counters advance independently:

inc → 1, inc → 2, inc$0 → 1, inc → 3, inc$0 → 2

A shared-state (H-1) corruption would make inc$0's first call return 3 — the
load-bearing assertion is that it returns 1.

Verification

• Differential execution oracle green (independent mutable state proven).
• 6 structural unit tests (core_instance_topology::tests).
• Full meld-core suite green — 0 failures, no regression (the pass is a
  no-op for single-instantiation components; the SR-31 reject is retained as an
  unreachable backstop, ls_m_5 still passes).
• fmt + clippy clean; rivet validate PASS.
• SR-55 (implemented) — duplicate-support capability, refines SR-31,
  mitigates LS-M-5; SR-31 noted as superseded for handleable cases.

Notes

• The two instances both export the core name inc; meld disambiguates the
  second with a $0 suffix (existing identical-name dedup).
• Tier-5 (lib.rs merge-pipeline wiring) → Mythos delta-pass to follow.

Refs #354 (ADR-7 path-H inc 3), RFC-46 Q1

[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.}