Fix invalid WebAssembly lowering for Unit externs and typed locals #377

Problem

Ephapax can typecheck a host extern program and then emit structurally invalid WebAssembly in two related lowering cases:

1. A language-level Unit expression is represented internally as i32 0, but a Unit-returning WebAssembly import correctly has no result. Direct extern calls do not restore the language-level Unit value, leaving the caller's result stack empty.
2. Every non-parameter local is declared as i32, even when an explicitly typed let binding is I64, F32, or F64. Storing an I64 extern result therefore produces an i64/i32 local mismatch.

The first defect was reduced to a minimal notify(I32): Unit extern call. Repairing it allowed the real Gossamer CLI to advance and reveal the second defect in its cap_token(I32): I64 / i64_is_zero(I64): I32 path.

Required correction

• Preserve the concrete WebAssembly type of explicitly typed local bindings in declaration order.
• After a Unit-returning extern call, reconstitute Ephapax's language-level Unit representation without changing the host ABI.
• Add validator-backed regression tests for both failures.
• Validate the actual Gossamer cli/src/Main.eph module with the corrected compiler.

Acceptance criteria

• Both minimal regressions emit modules accepted by wasmparser::Validator.
• The Gossamer CLI source compiles to a structurally valid WebAssembly module.
• cargo fmt --all --check passes.
• cargo clippy --workspace --all-targets --all-features -- -D warnings passes.
• cargo test --workspace --all-features passes.

This must be fixed in Ephapax rather than by falsifying the Gossamer host signature or avoiding the affected expressions.