fix: Handle Wasm ValueTypes returned by imports

[blaine-arcjet]

This reworks Wasm imports to build functions with explicit Wasm ValueTypes based on the Wasm signature provided by the WIT tooling. This requires that we use the stack provided by Wazero but that makes using the various api.Decode* and api.Encode* functions work correctly on Wasm imports.

I believe this resolves some issues introduced by my changes in #96

---

Changes made to finish this pull request

blaine-arcjet has left Arcjet, so this pull request was completed with Claude Code. The last two commits replace the approach described above. The earlier commits stay in the branch history.

Why the approach changed. The original commits moved import handling out of func.rs into a separate imported_func.rs and built each host function from wazero's stack. Since then, main has kept import handling in func.rs behind Direction::Import and added records, variants, options, enum lifting and indirect parameters there, none of which the separate file has. At this branch's previous head, every scalar import return type except u32, bool and string still reached todo!("TODO(#9): handle return type"). Merging main into the branch therefore takes main's func.rs in full and removes imported_func.rs, and the fix is built on main's structure.

What was wrong on main. Gravity registers each host import with wazero's WithFunc, which reads the function's Wasm signature from its Go types: uint32 for i32, uint64 for i64, float32 and float64 for the floats. The scalar lowering instructions produced the uint64 encoding that api.Function.Call expects instead. An import returning s32, s8, u8, s16, u16, f32 or f64 generated Go that did not compile, and one returning s64 or char made gravity panic.

What this changes.

• The integer lowering instructions emit uint32(x) and uint64(x). Go's conversion sign-extends signed values, so once CallWasm widens the result to uint64, exports receive the same value api.EncodeI32 produced.
• The float lowering instructions pass the value through for imports and keep api.EncodeF32/EncodeF64 for exports, because uint64(float) converts the number rather than copying its bits.
• S64FromI64, I32FromChar and CharFromI32 are implemented, and WIT char maps to Go rune. Lifting a char rejects surrogates and values above U+10FFFF.

Tests. The get-u32 round-trip test from the original commits is kept. The iface-method-returns-string example gains a host import and an export for each scalar type, with Go tests that send boundary values (minimum, maximum, -1, ±Inf, U+10FFFF) through the guest and back.

Co-authored-by: 零Rei 212411920+arcjet-rei@users.noreply.github.com

🤖 Generated with Claude Code

[blaine-arcjet]

This caused some other problems in codegen so I'm drafting it.

[arcjet-rei]

Vale @blaine-arcjet! Thanks for putting this together, and I hope this implementation meets with your approval.