Wasm memory.copy overlap lowers to forward-copy semantics

## Summary

Wasm `memory.copy` has memmove-style overlap semantics, but the current lowering routes it to `builder.memcpy`, whose fallback loop copies forward. For overlapping ranges with `dst > src`, the generated behavior can alias its own writes and produce different memory contents than the Wasm source program.

Affected commit checked: `17eb665e52f3c2a519f8aa58c7dff1335ba63887` on `next`.

## Steps to reproduce

Public repro:

https://github.com/Kuhai9801/miden-int32-to-uint-ci/actions/runs/27597467549

The repro compares Wasm overlap behavior against the current forward fallback loop for:

```text
memory = [1, 2, 3, 4, 5, 6]
memory.copy(dst = 1, src = 0, len = 4)
```

## Expected behavior

The result should preserve the original source range:

```text
[1, 1, 2, 3, 4, 6]
```

## Actual behavior

The forward loop re-reads bytes it just wrote:

```text
[1, 1, 1, 1, 1, 6]
```

## Notes

`frontend/wasm/src/code_translator/mod.rs` lowers `Operator::MemoryCopy` directly to `builder.memcpy`. The fallback path should either copy backward when ranges overlap in this direction, use a temporary buffer, or otherwise implement Wasm `memory.copy` semantics.

The issue is in `frontend/wasm/src/code_translator/mod.rs` where `Operator::MemoryCopy` is lowered to `builder.memcpy`. Examine the fallback loop logic for overlapping copies where `dst > src`. A test case is provided in the repro link. To verify the fix, run the existing test suite and the specific reproducer to ensure the memory contents match the expected Wasm semantics.

Written by the indexing model from the issue text.