Linker: an external's global initializer is parsed before the tier gate, producing a misleading error for position-independent builds

[0xGeorgii]

Problem

collect_global runs on external modules during parse — before tier classification and before the non-function-import check. It accepts only i32.const/i64.const initializers and hard-errors otherwise.

Since the global/table gate now keys on use rather than declaration, an external's globals are dropped by construction: the merged output emits the main module's globals only, and a closure that reads a global is still Tier C. So for an external, parsing the initializer expression is work whose only observable output is an error message about a global the merge never emits.

That message is actively misleading on the path users are advised toward. RequiresRelocatableBuild tells them to "build the external module with a relocatable/position-independent toolchain"; doing so produces a global.get-based (PIC) initializer, and the link then fails with:

unsupported WASM construct for static merge: unsupported global initializer for the
static merge: GlobalGet { global_index: 0 } (only i32.const/i64.const are modeled)

The near-identical shape without a global of its own reports the accurate, actionable error instead:

external module providing `sum` imports its environment

Same root cause, two different errors, and the misleading one lands on the shape the advice steers users to.

Proposal

Make collect_global role-aware, mirroring the existing role-based handling of the inference.spec_funcs / inference.hspecs custom sections: for an external module, retain nothing (or a kind-only record) and never inspect the initializer expression. The PIC case then falls through to the import check and reports "imports its environment", which is accurate.

This is strictly less code than today, and it makes "an external's globals are inert" structural rather than incidental.

Notes

• The reachable surface is narrower than it looks: a float global is caught by the feature gate first, ref.null/ref.func initializers need reference types (excluded), and extended-const is excluded. global.get of an imported global is essentially the only reachable case — which is exactly the PIC case above.
• Do not widen the modeled initializer set. Nothing consumes an external's global initializer.
• After the use-vs-declaration change, an external's parsed tables has no production reader at all and its globals are write-only apart from this parse failure; worth a look while here.

Found during a review of the tier declaration-vs-use change in #363.

Refs: #363, #420.