fix(noir-contracts): deliver notes via onchain_unconstrained in app/deployment contracts

[AztecBot]

What

Switch the note delivery in the account (ecdsa_r/ecdsa_k/schnorr), token and benchmarking contracts from MessageDelivery::onchain_constrained() to MessageDelivery::onchain_unconstrained(). No benchmark expectations are changed.

(Supersedes this PR's earlier approach of bumping the expectedExecutionSteps(...) inputs — per the fairies team the extra step isn't wanted here.)

Why

#24223 (merge-train/fairies-v5 → v5-next) kept getting dequeued. After the compile fix (#24323), the full merge-queue lane failed on three benches, all traced to one cause:

• client_flows/account_deployments — Expected 10 execution steps, got 11
• client_flows/amm (add_liquidity) — Expected 14 execution steps, got 17
• bench_build_block — repeated Failed to commit transaction: … Tagging window length 20 is configured too low → 600s timeout

These contracts delivered notes with onchain_constrained(), which was effectively a no-op on v5-next. #23866 — wire constrained message delivery (on the train) made that mode issue a real validate_handshake private call on the first send (index 0) of each (sender, recipient, secret) sequence. Once v5-next merged into the train:

• every cold constrained send gained one extra app circuit (the handshake bootstrap) → the step-count benches above; and
• the per-secret tagging index advanced on each send, so bench_build_block (which emits many notes to one recipient before finalization) blew past UNFINALIZED_TAGGING_INDEXES_WINDOW_LEN = 20 (yarn-project/pxe/src/tagging/constants.ts:10), failing every tx commit until timeout.

These flows test app/deployment logic and don't need constrained delivery — that has dedicated coverage in constrained_delivery_test_contract. So deliver via onchain_unconstrained(), the behavior these benches were written against.

Why no benchmark-expectation changes

The onchain_constrained() usage and the bench expectations both came from v5-next, where the mode was a no-op — so the existing expectedExecutionSteps(...) inputs already encode the unconstrained (no-bootstrap) counts. Reverting the contracts to unconstrained makes the actual counts match them again (account_deployments → 10, amm → 14). The warm-send benches (transfers, bridging) never hit a cold bootstrap, so they're unaffected either way.

Scope / verification

• Touches only the account / token / benchmarking contracts the failing benches exercise (plus ecdsa_k for account-contract consistency). The dedicated constrained_delivery_test_contract is intentionally left untouched.
• These client_flows benches run only in the full/merge-queue lane, not in this PR's fast CI, so the authoritative check is re-queuing feat: merge-train/fairies-v5 #24223 (or a CI_FULL run). A local build/run wasn't possible in this container (no docker/cache; needs the noir submodule).
• Other app/test contracts (nft, escrow, counter, simple_token, …) still use onchain_constrained(). If you want the full "unconstrained everywhere" sweep (which also touches e2e discovery tests), say the word and I'll extend it — kept scoped here to what unblocks feat: merge-train/fairies-v5 #24223.

cc @vezenovm @nicolas-venturo — this implements the onchain_unconstrained switch you described.

[vezenovm]

Superceded by #24336, will do a test token contract split separately