fix(353): fold extended-const (base+N) data/element offsets — completes inc-4 fold

[avrabe]

Completes the inc-4 static-PIC offset fold (#365) — which had a real gap found
by the inc-4 Mythos discover agent (it died on a session-limit but left the
reproducing oracle behind).

The gap

#365 folded the bare (data (global.get $base) …) shape but left the
extended-const (data (i32.add (global.get $base) (i32.const N)) …) shape as
a verbatim global.get. But wasm-tools component link emits the extended-const
form for every N > 0 data segment (only N == 0 is bare) — so the common PIC
case was still emitted as global.get <defined base>; i32.const N; i32.add,
which wasm-tools accepts (lenient) but wasmtime rejects ("constant expression
required: global.get of locally defined global"). Silent invalid output.

The fix

ParsedConstExpr::reindex's ExtendedGlobalGet arm now folds the whole
base ± N expression to a single i32.const when the leading global is a
defined constant-i32 (reusing the defined_global_i32_consts map from #365),
via a small stack evaluator eval_ext_const_i32_with_base. It declines (and
leaves the expression verbatim) when:

• the base is imported (meld fuse silently truncates extended-const exprs beginning with global.get (drops trailing arithmetic) — corrupts global initializers + data/element offsets (PIE base+N) #338 — runtime-dependent, stays a global.get),
• a non-leading global.get appears (value depends on a 2nd global),
• any i64 op appears (not a 32-bit memory offset), or
• the sequence is unbalanced.

Verification

• Execution oracle pic_extended_const_data_offset_valid_for_wasmtime_353 —
  a PIC-pattern component with an extended-const base + N data offset fuses,
  validates for wasmtime, and reads the data back correctly. Was FAILING
  on main before this fix.
• Unit test covering base±N / base*N / bare, plus all three decline cases.
• The feat(adr7): static-PIC data/element-offset fold — inc 4 (#353) #365 bare-fold oracles still green; full meld-core suite green (0
  failures); fmt + clippy clean.

Tier-5 (segments.rs) → Mythos delta-pass below.

Refs #353 (ADR-7 path-H inc 4), #365, #338.

[avrabe]

Mythos discover pass (extended-const offset fold) — NO FINDINGS

Self-conducted (backed by the execution oracle + a unit test on the evaluator's decline cases) + CI auto-Mythos as the independent second check. Hypotheses examined against the diff (segments.rs):

1. Folds an imported base? No — the fold only fires when the leading global's post-remap index is in defined_global_i32_consts, which is populated ONLY for DEFINED immutable constant-i32 globals (feat(adr7): static-PIC data/element-offset fold — inc 4 (#353) #365). An imported __memory_base is absent → the extended-const stays verbatim (meld fuse silently truncates extended-const exprs beginning with global.get (drops trailing arithmetic) — corrupts global initializers + data/element offsets (PIE base+N) #338 runtime-dependent shape preserved).
2. Wrong folded value? eval_ext_const_i32_with_base is a straight i32 stack machine using wrapping_{add,sub,mul} (matches wasm i32 semantics). The execution oracle checks the data reads back correctly at the folded address; the unit test pins base±N, base*N, and bare-base.
3. Over-folds a genuinely runtime-dependent expr? Declines (returns None → verbatim) on: a NON-leading global.get (value depends on a 2nd global), any i64 op, or an unbalanced stack. Unit-tested.
4. Element segments? The fold is in ParsedConstExpr::reindex, shared by data AND element offsets — both covered by the same change.
5. Interaction with the bare-fold (feat(adr7): static-PIC data/element-offset fold — inc 4 (#353) #365)? Independent match arms (GlobalGet vs ExtendedGlobalGet); the feat(adr7): static-PIC data/element-offset fold — inc 4 (#353) #365 bare-fold oracles stay green.

Empty-default defined_global_i32_consts → inert for every other caller. Full suite green; fmt + clippy clean. No finding reported.

[github-actions]

Mythos delta-pass required

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

meld-core/src/segments.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.

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

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