Allocate memory for contract-call? args representation

[BowTiedWoo]

This PR changes how we allocate memory space when writing argument representations.

Previously, we used get_type_in_memory_size to calculate space for all arguments, which often over-allocated memory unnecessarily.

Now, we only allocate space for list arguments — the only type whose representation is written directly to the offset.

stacks-core/clarity/src/vm/clarity_wasm.rs

Lines 1736 to 1745 in fa0a21c

	for item in &l.data {
	let (len, in_mem_len) = write_to_wasm(
	&mut store,
	memory,
	ltd.get_list_item_type(),
	offset + written,
	in_mem_offset + in_mem_written,
	item,
	true,
	)?;

All other types are written to in_mem_offset inside the pass_argument_to_wasm function and do not require reserved space at offset.

Closes: stacks-network/clarity-wasm#633

[Acaccia]

This is incorrect globally.
The discussion we had that lead to this fix was flawed.

More than that, we have many types that would write at offset, the description is incorrect.

[BowTiedWoo]

Thank you for the feedback!
Here’s the reasoning behind the PR description:

In pass_argument_to_wasm, the following types write directly to in_mem_offset using memory.write():

• StandardPrincipal
• ContractPrincipal
• StringASCII
• StringUTF8
• Buffer

For List, each item uses write_to_wasm, which:

Writes to offset:

• int, uint, bool (just value);
• buffer, string, list, principal (offset + length);
• optional, tuple, response (indicator bytes, possibly recursive)

Writes to in_mem_offset: buffer, string, principal (just the data)

So, only List reliably writes to both offset and in_mem_offset. Others either skip writing or only write at in_mem_offset.
(optional, tuple, and response can include nested types like List, but I haven’t fully traced that yet.)