test: harden public EVM-Aztec E2E and fix lock reconciliation

[arkoc]

Summary

• Run the EVM-Aztec fund-safety suite through public Station and public chain RPCs only.
• Remove Admin API and internal-service dependencies from the E2E path.
• Add bounded public EVM and Aztec clients, strict route/economics validation, failure recovery, report redaction, and edge-case coverage.
• Fix Aztec SolverLocked decoding so its 32-byte reward-token address is preserved when the counterparty chain is EVM.
• Add a regression for the exact EVM-to-Aztec direction that previously left Station orders in Created.

Root cause fixed

SolverLocked.reward_token is an AztecAddress belonging to the chain where the solver lock exists. The decoder incorrectly normalized it using dst_chain. For an EVM counterparty this truncated the 32-byte Aztec token to 20 bytes, so the workflow correctly rejected the event as an economics mismatch even though the on-chain lock was canonical.

The fix removes only that invalid conversion. Strict workflow event validation remains unchanged.

Validation

• Aztec v5 service: 15/15 tests passed.
• Swap workflow safety: 64/64 tests passed.
• Core event ingestion: 17/17 tests passed.
• Public E2E helpers and preflight: 21/21 tests passed.
• Public Aztec-to-EVM execution completed successfully before this fix.
• Public EVM-to-Aztec execution reproduced the decoder issue and both HTLCs were recovered through public chain methods.

A funded post-fix public rerun must happen after the updated Aztec service image is deployed; the currently deployed service still contains the defective decoder.

Remaining concern

The advertised exact route minimum and maximum are rejected by the solver in both directions. That P1 boundary inconsistency is unrelated to this decoder fix and is intentionally not mixed into this PR.

Security

Reports redact wallet secrets and private account material. No credentials or recovery secrets are committed.