chore: upgrade wirm from 2.1.0 to 4.0.4

[venkkatesh-sekar]

Adapt to wirm 4.0.4 API breaks. Mostly mechanical, but two API changes (Module::parse and Instructions::new) gained extra parameters that need deliberate values, and several methods now return Result where they used to be infallible.

API changes and chosen values

Module::parse(wasm, enable_multi_memory) → Module::parse(wasm, enable_multi_memory, with_offsets)

All callsites pass false for the new with_offsets parameter.

with_offsets controls whether wirm records each operator's static PC offset within the function body during parsing. We don't need it: instrumentation walks instructions structurally (by index in body.instructions), never by source byte offset. Saving offsets would only add memory overhead for data we never read.

Instructions::new(Vec<Operator>) → Instructions::new(Vec<(Operator, usize)>, locals_start, save_offsets)

All callsites pass save_offsets = false and locals_start = 0, and map each operator to (op, 0).

save_offsets controls whether wirm stores per-operator PC offsets on the resulting Instructions. We're constructing fresh synthetic instruction sequences (helper functions, replacement bodies, instrumented bodies), not parsing existing bytes — there is no real PC to record, and downstream code never reads these offsets. With save_offsets = false, the per-operator usize and locals_start are both unused (wirm only consults them inside the if save_offsets branch to compute offset - locals_start). We pass 0 in both spots as an unambiguous "unused" sentinel.

wasmparser::TypeRef::FuncExact(_) (new variant)

Added a match arm in validate_import_section that rejects it with the same InvalidImportSection error used for Tag imports. We don't support exact-typed function imports — IC0 imports use ordinary Func, and accepting FuncExact would require type-equality plumbing we don't need.

Methods that now return Result

The wirm 4.0.4 versions of unwrap_local_mut, get_ops_mut, params, encode, and replace_import_in_module all return types::Result<_> instead of panicking / returning the bare value. Where the surrounding context guarantees the call can't actually fail, we use .expect(...) with a message documenting why it can't fail. Specifically:

Site	API call	Why the error case is unreachable
inject_metering (instrumentation.rs:1324)	get_ops_mut()	Errors only if the body's Instructions has instrumentation flags set. Flags are only set by wirm's iterator-based injection API (before/after/alternate), which we never call — we manipulate body.instructions directly.
inject_try_grow_wasm_memory (instrumentation.rs:1425)	get_ops_mut()	Same as above.
replace_system_api_functions (instrumentation.rs:1500)	replace_import_in_module(id)	Errors only if the import at id isn't a TypeRef::Func. The id comes from calculate_api_indexes, which filters with matches!(imp.ty, TypeRef::Func(_)) before producing indexes.
instrument (instrumentation.rs:1593)	unwrap_local_mut()	Errors only if the function isn't local. The directly upstream .filter(|f| f.is_local()) already guarantees this.
instrument (instrumentation.rs:1614)	unwrap_local_mut()	Same as above.
instrument (instrumentation.rs:1621)	params()	Errors only if the resolved type isn't a FuncType. The lookup uses func_body.ty_id, and per the wasm spec a function's type index must reference a function type — enforced by the wasm validator that already ran.

module.encode() is the one fallible call we genuinely propagate (via WasmInstrumentationError::WasmSerializeError), since serialization can in principle fail on malformed instrumented output.

Test plan

• bazel test — 33 directly-affected targets pass (//rs/embedders:*, //rs/execution_environment:execution_environment_misc_integration_tests/*, //rs/test_utilities/execution_environment:*)
• cargo clippy clean on ic-embedders and embedders_bench