feat(aztec-nr): sender-side support for interactive handshakes

[nchamo]

Motivation

The handshake registry has an interactive_handshake entrypoint (#24473), but no sender can reach it: the delivery stack only knows how to establish non-interactive handshakes.

The change

Senders can now choose an interactive handshake the same two ways non-interactive ones are chosen:

• In-contract: a via_interactive_handshake() builder option on both onchain delivery modes, flowing through a new TagDerivation kind and TagSecretSource kind that call the registry's interactive_handshake entrypoint via a new pinned selector.
• By the wallet: an interactive-handshake variant in the TaggingSecretStrategy hook union and in ResolvedTaggingStrategy (TS and Noir in lockstep).

Defaults do not change: interactive is strictly opt-in. Like a fresh non-interactive handshake, a fresh interactive one backs both delivery modes and starts its constrained sequence at index 0; an existing handshake of either type is reused before establishing a new one.

The oracle version minors are bumped since no existing contracts were using this oracle yet.

Fixes F-786

[vezenovm]

Niceee

[vezenovm]

Suggested change

	///
	/// The registry obtains the recipient's signed authorization through a
	/// [`resolve_custom_request`](crate::oracle::resolve_custom_request::resolve_custom_request) oracle call it resolves
	/// internally, verifies it in-circuit, inserts a fresh handshake note and returns the secrets. Nothing announcing the
	/// handshake is published onchain: the recipient learns the shared secret while signing. As with
	/// As with

we probably don't need to repeat this information again. it can all be found by looking at the registry method's doc comments.

[vezenovm]

Suggested change

	/// An interactive handshake: the recipient learns the secret while signing its authorization, and nothing
	/// announcing the handshake is published onchain. See
	/// [`create_interactive_handshake`](super::handshake::create_interactive_handshake) for how the registry obtains
	/// that authorization.
	/// An interactive handshake: the recipient learns the secret while signing its authorization.

feel like this is enough

[vezenovm]

Suggested change

	/// Establishes a fresh interactive handshake, publishing nothing about the recipient onchain. See
	/// [`create_interactive_handshake`](super::handshake::create_interactive_handshake) for how the registry obtains
	/// the recipient's signed authorization.
	/// Establishes a fresh interactive handshake, publishing nothing about the recipient onchain.

same here. I think it is clear we should reference the registry. Or we can say to reference the registry for more info.

[vezenovm]

is this needed?