refactor(adr7): extract the address-strategy seam from the merger (path-H inc 1)

[avrabe]

Executes ADR-7 path-H, increment 1 (#354): extract the per-module
address/memory strategy resolution out of Merger::merge into a dedicated
address_strategy module — behavior-preservingly. This is the pluggable seam
the decided architecture hangs off.

What

• address_strategy.rs — AddressPlan + resolve_address_plan, holding the full
  decision + validation (ADR-6 path-F MissingRelocMetadata, memory64 reject,
  the meld --memory shared --address-rebase skips R_WASM_MEMORY_ADDR_SLEB relocations: a rebased module's i32.const data pointer stays stale -> silent cross-component aliasing (gap in #340) #351 MisalignedReloc backstop). has_direct_memory_access is passed as a
  closure so the original lazy short-circuit (only a non-zero-base, no-reloc
  module pays the probe) is preserved exactly.
• merger.rs — the ~50-line reloc-consumption block replaced with one call.
• 4 focused unit tests (rebasing-off / base-0 / no-reloc-direct → hard-fail /
  bulk-only → empty, plus closure-laziness).

Scope of AddressPlan (does not affect multi-memory + FACT fusion)

An AddressPlan carries only which relocation sites to shift for a non-zero
shared-memory base — nothing else. Under multi-memory, each component keeps
its own linear memory at its own base, so there are no sites to shift and the
plan is empty. An empty plan means "no address rebasing needed here" — it
is not a disablement of fusion, and it does not touch cross-component
adapter (FACT) generation, transcoding, or any other part of the merge. Those
run identically regardless of what this seam resolves. Multi-memory + FACT stays
the generic, first-class fusion path (ADR-7's canonical / open profile);
multi_memory fixtures remain green (6/6).

The shared-rebase strategy now lives here. Static-base PIC (#353) and the
per-boundary call-lowering seam are the next increments — they plug in here
without touching the merger's hot path.

No behavior change

Canonical gating fixtures (test_326_reloc_const_rebasing_end_to_end,
test_address_rebasing_end_to_end) + drop_realloc + full meld-core suite all
green; fmt + clippy clean. Pure structural extraction.

Tier-5 (merger.rs + new fusion-critical module) → Mythos discover pass to follow.

Refs #354 (ADR-7)

[github-actions]

Mythos delta-pass required

This PR modifies one or more Tier-5 source files (per
scripts/mythos/rank.md):

meld-core/src/merger.rs

Before merge, run the Mythos discover protocol on the
modified Tier-5 files:

1. Follow scripts/mythos/discover.md
   — one fresh agent session per touched Tier-5 file.
2. For each finding, the agent must produce both a Kani
   harness and a failing PoC test (per the protocol's
   "if you cannot produce both, do not report" rule).
3. Attach a comment on this PR with either the findings
   (formatted per discover.md's output schema) or
   NO FINDINGS.
4. Add the mythos-pass-done label to this PR.

Why this gate exists: LS-A-10
(CABI alignment padding in async-lift retptr writeback) was
found by the v0.8.0 pre-release Mythos pass — but it had
lived in the callback emitter since #128, across six
releases. A PR-time gate would have caught it at review
time instead of at the release boundary.

The gate check on this PR will pass once the label is
applied.

[avrabe]

Mythos delta-pass — finding

Clean-room adversarial pass focused on the one thing that matters for a
behavior-preserving refactor: is resolve_address_plan semantically identical
to the inline block it replaced?

Verdict: CLEAN — behavior-identical, verified branch-by-branch against the
removed merger block:

• Short-circuit / laziness (the risk): the has_direct_memory_access closure
  is invoked in the same position of the same && chain, so
  module_has_direct_memory_access is called only when base != 0 && !has_reloc,
  at most once, with ? propagated identically. Pinned by two dedicated laziness
  unit tests.
• Return values: every branch (rebasing-off / base-0 / no-reloc / has-reloc /
  memory64 / misaligned) returns the same code_addr_relocs and data_addr_relocs
  (the old let mut … = empty default is mirrored by AddressPlan::default()).
• Errors: MissingRelocMetadata / UnsupportedFeature (memory64) /
  MisalignedReloc fire under identical conditions with identical fields; the
  memory64 format string is byte-for-byte identical.
• Only diff: component_display_name is now evaluated eagerly per module (one
  redundant String alloc) — pure/total (.get(), no panic, no side effects), so
  a performance detail, not observable behavior.

No divergent input exists → no oracle can fail → nothing reported. Gating fixtures
(test_326_reloc_const_rebasing_end_to_end, test_address_rebasing_end_to_end,
test_351_…, test_326_shared_rebase_without_relocs_hard_errors) + drop_realloc +
address_strategy unit tests all green.

Adding mythos-pass-done.

[github-actions]

Mythos delta-pass (auto)

✅ NO FINDINGS across 1 Tier-5 file(s)

File	Verdict	Hypothesis
``	✅ NO FINDINGS	—

_{Auto-run via anthropics/claude-code-action@v1
(SHA-pinned) on the touched Tier-5 files, using the
maintainer's Max-plan OAuth token. See
.github/workflows/mythos-auto.yml and
scripts/mythos/discover.md.}

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

[avrabe]

Good question — short answer: no, nothing about the generic multi-memory + FACT path is stopped or changed. "Empty plan" is a no-op, not a disablement. Let me be precise about the wording.

AddressPlan is only about address rebasing — which reloc.CODE/reloc.DATA R_WASM_MEMORY_ADDR_* sites the rewriter must shift when a module is placed at a non-zero shared-memory base. That's its entire scope:

pub struct AddressPlan {
    pub code_addr_relocs: Option<HashSet<u32>>,   // code sites to rebase
    pub data_addr_relocs: Vec<RelocEntry>,        // data pointers to rebase
}

Multi-memory has no addresses to rebase — each component keeps its own linear memory at its own base, so no absolute address ever collides with another component. There's simply nothing to shift → an empty plan. That's exactly what multi-memory did before this PR; the refactor just gives that "no rebasing needed" case a name. resolve_address_plan returns the empty plan whenever address_rebasing is off (which multi-memory always is).

FACT is a separate subsystem and is completely untouched. This refactor has zero references to adapter/FACT in either changed file (grep-confirmed). Cross-component calls under multi-memory still generate the FACT trampolines (cabi_realloc in the callee's memory + memory.copy between memories) exactly as before — the adapter subsystem is wired from lib.rs, not the merger, and this PR doesn't go near it.

Verified: the multi-memory test suite is green (6/6), and the whole change is Mythos-reviewed as behaviour-identical to the pre-refactor block (it's a pure extraction).

Bigger picture (ADR-7 / #354): the decided architecture deliberately keeps multi-memory + canonical FACT as the first-class, universal path — it's the open/ecosystem profile and the canonical fallback that preserves mix-and-match with any component. The symmetric/PIC "fast lane" that this seam will later enable is strictly additive and opt-in — it never removes or degrades the generic multi-memory + FACT fusion. That non-negotiable is written into ADR-7 as a hard requirement.

[avrabe]

Fixed the misleading phrasing in both places — the module doc (address_strategy.rs) and this PR description now spell out the scope explicitly:

An AddressPlan carries only which relocation sites to shift for a non-zero shared-memory base. Under multi-memory each component keeps its own memory at its own base, so the plan is empty — meaning "no address rebasing needed here", not that fusion is disabled. It does not touch cross-component adapter (FACT) generation, transcoding, or any other part of the merge.

So to answer directly: no, multi-memory + FACT fusion into a core module is not stopped. That path is unchanged by this seam (multi_memory fixtures 6/6 green); the "empty plan" is just the absolute-address rebaser having nothing to do when memories aren't shared. This PR is a pure structural extraction of the shared-rebase decision — FACT/transcoding code isn't referenced in any changed file.