test(e2e,bridge): approval ordering — approve-before-sign vs approve-after-sign both claim

[rsporny]

Summary

The unsigned-first tx flow makes the Cardano tx hash invariant under signing, so a hash can be pre-approved before the tx is signed/submitted. Add an e2e case covering both operational orderings, both ending in a successful claim:

1. prepare → pre-approve (unsigned hash) → sign & submit → claim
2. prepare & sign → pre-approve (signed hash) → submit → claim

Both must produce a BridgeUserTransfer for the same mc_tx_hash and a claimable record; the recipient claims mNIGHT 1:1 minus fee.

Why

Hash invariance is only unit-covered today (partner-chains/toolkit/smart-contracts/offchain/src/sign_tx.rs; old cases 2.1/2.2). The end-to-end guarantee — that a pre-approval on the unsigned hash matches the on-chain submitted tx — is unasserted e2e. This is exactly the ordering the demo dApp (midnightntwrk/bridge-demo-dapp#3) implements (allowlist the hash, then sign + submit), so it is the real operator flow.

Suggested level — e2e

• E2E in tests/e2e/tests/c2m_bridge.rs: parametrize the two orderings over the existing lock→approve→claim helper; assert both reach Ready-to-Claim under the same hash and claim successfully.
• Extends E1 (approved user transfer → claim).

Notes

Surfaced during the QA bridge test-plan coverage review; ties to the demo dApp operator flow.