feat(e2e): interactive handshake e2e

[nchamo]

Motivation

With sender-side selection (#24522) and recipient-side registration (#24514) in place, the interactive handshake flow had no end-to-end coverage. The only producer of a valid RecipientSignature was the offline script that generated the Noir test fixture, and TXE only covers the no-resolver failure path.

The change

• Adds interactive handshake x constrained and unconstrained cells to the delivery matrix, exercising the full round-trip across two PXEs: the sender's PXE requests the recipient's authorization through the resolveCustomRequest hook, the recipient registers the handshake on its own PXE and answers with a RecipientSignature the registry verifies in-circuit, and delivery proceeds under the resulting shared secret.
• The test serves the signature request in-process: it parses the request, signs with the master message-signing key, and serializes the response to the exact field layout the circuit deserializes.
• Extends the delivery harness with a customRequestResponder option and a baseline assertion that the hook fires exactly once per cell.
• Adds INTERACTIVE_HANDSHAKE_REQUEST_KIND to @aztec/standard-contracts/handshake-registry so the contract's request kind has one TS definition.

Fixes F-787

[vezenovm]

Awesome! Some small comments.

We can discuss a more public API as a follow-up. I am good with having the responder be localized to tests at this stage (better to have the e2e tests).

[vezenovm]

We should be able to use the #[abi] attribute in the contract on this global and then we can access the constant through the contract artifact. We then do not risk any constant drift.

[nchamo]

Claude is telling me that #[abi] only supports literal constants. So we wouldn't be able to use sha256_to_field("HANDSHAKE_REGISTRY::INTERACTIVE_HANDSHAKE_REQUEST".as_bytes())

Do you know if it's correct?

[nchamo]

If Claude is correct, then I would try to keep the current version instead of using a "magic" literal value. This test would actually catch any drifts, so I think we would be safe

[vezenovm]

#[abi] only supports literal constants

Claude is right and it is actually worse. Confirmed with a minimal repro against the nargo we pin (beta.22). A computed initializer like sha256_to_field(...) on an #[abi] global (even 40 + 2) crashes the compiler with an internal panic during ABI emission. noir-lang/noir#12714 fixes the panic in beta.23.

Separately, exported globals are unnamed in the artifact until beta.23 (noir-lang/noir#12620).

Let's just leave a TODO marker here that we can remove this mirrored constant at the next Noir release.

[vezenovm]

#[abi] only supports literal constants

Claude is right and it is actually worse. Confirmed with a minimal repro against the nargo we pin (beta.22). A computed initializer like sha256_to_field(...) on an #[abi] global (even 40 + 2) crashes the compiler with an internal panic during ABI emission. noir-lang/noir#12714 fixes the panic in beta.23.

Separately, exported globals are unnamed in the artifact until beta.23 (noir-lang/noir#12620).

Let's just leave a TODO marker here that we can remove this mirrored constant at the next Noir release.