Break the rematerialization work into ISS-404 through ISS-407, and fix two invalid issue types

[Milky2018]

ISS-403 (merged in #495) recorded the defect and, after reading Cranelift, the shape of the fix. This splits the work so the ordering is a dependency graph rather than prose. Tracker files only — no code changes.

issue	depends on	what
ISS-404	—	Materialization-cost predicate
ISS-405	ISS-404	Rebuild marked values once per using block
ISS-406	ISS-405	Fold the AArch64 EnvironmentField remat into the shared mechanism
ISS-407	—	Fold constant offsets into load/store displacements

ISS-403 now depends on all four and closes on the observable outcome. ISS-404 and ISS-407 are in the ready queue.

Why ISS-404 exists at all

It is the piece Cranelift structurally lacks. Their remat rules live in the target-independent mid-end, so they cannot consult a cost — which is why remat.isle marks every iconst, f32const and f64const regardless of what materializing one actually costs on the target.

Measured on AArch64, against the 1-instruction reload it would replace:

value	instructions
5, 1020, 65535, 65536	1
4294967295, 305419896	2
81985529216486895	4
f64.const 3.14159	5

At one instruction, rebuilding matches the reload and additionally saves the spill store, the stack slot and the cross-block live range — a strict win. At four or five it is several times the reload. The measured fixture's addresses are all in the 1-instruction band, so a cost-gated rule captures the full 2× while staying safe on wide constants.

The first cut is conservative and target-independent (single-movz form, also one instruction on x64), with a cost-callback seam left for the caller that already knows the target. Wasmoon has an advantage here that Cranelift does not: optimize_with_level is a plain function call from a JIT that already resolved the target, where Cranelift's ISLE rules are compiled ahead of time.

Two non-goals, recorded rather than left implicit

Both are places where copying Cranelift would be wrong here:

• The ALU-with-one-constant-operand rules. Rematerializing y = a + k swaps which value is live rather than reducing the count, and since remat does not recurse, it can move the long live range onto a instead. Cranelift's own comment only claims "neutral" for this case.
• Float and vector constant remat. Five instructions on AArch64 against a four-byte reload.

Also worth noting for whoever picks this up: Cranelift's saturating_sub(1) LICM hoist-level default is a magic constant compensating for the missing cost model — the comment says as much, citing vconst not being easily rematerialized. With a cost predicate that special case is unnecessary.

Second commit: two invalid issue types

ISS-398 and ISS-399 were typed refactor, which the tracker does not define — its five types are bug, feature, task, epic and chore, and task explicitly covers "implementation, tests, docs, or refactoring work".

The effect was a warning on every index regeneration plus a bogus refactor entry in the type column for ISS-399, which is open and therefore listed. ISS-398 is closed, so it only appeared in the warnings. Warnings are now empty, and a sweep over the other 402 issue files finds no further invalid types.

Carried on this branch rather than its own: both changes rewrite the derived issues/README.md, and separate PRs would conflict the moment either merges.