feat(pxe): resolve tagging secret strategy via wallet hook

[nchamo]

Motivation

There are several ways to deliver a message between users, each with a different privacy trade-off. Delivery can reuse a secret the two parties already share (a previously established handshake, or one agreed off-chain) and leak nothing. Or it can establish a non-interactive handshake on the fly, which works without coordination at the cost of publishing information about the recipient onchain. When no tagging secret has been established for a (sender, recipient) pair yet, someone has to decide how to source one. That decision belongs to the wallet, which owns the user's privacy stance and can ask the user if needed.

The change

aztec-nr gains a resolve_tagging_strategy(sender, recipient, mode) oracle. It is consulted only when no tagging secret has been established for the (sender, recipient) pair yet; an established secret is reused without asking. The send flow will call it when resolving the tagging secret (F-698, not wired in this PR).

The wallet expresses its decision as a TaggingSecretStrategy: which secret to use, plus any raw material PXE cannot derive on its own (an arbitrary secret point). PXE resolves that strategy, performing any Diffie-Hellman key exchange and app-siloing, and returns a ResolvedTaggingStrategy the contract uses directly. So wallets never reimplement the derivation, and the contract never sees raw key material. There are three strategies:

• Non-interactive handshake — a secret the recipient derives from an onchain handshake. Works without prior coordination, but publishes information about the recipient onchain. Constrained or unconstrained.
• Address-derived — derived from the sender's and recipient's address keys via Diffie-Hellman. PXE does the exchange, so the wallet supplies no material. Leaves no onchain trace; unconstrained only.
• Arbitrary secret — a raw secret point the two parties already share off-chain. The wallet supplies the point and PXE app-silos it. Leaves no onchain trace; unconstrained only, since constrained delivery requires the secret to be backed by an onchain handshake, which this lacks.

PXE answers the oracle through a new optional resolveTaggingSecretStrategy execution hook. We chose a hook over a static config value because the decision is per message. The request carries:

• the executing contract (address and class id)
• the message's sender
• the message's recipient
• the delivery mode (constrained or unconstrained)

This lets wallets apply per-application or per-recipient policies, or surface the decision to the user. The hook follows the existing precedent of authorizeUtilityCall, PXE's other wallet policy callback.

When no hook is configured PXE applies a privacy-safe default: unconstrained delivery uses an address-derived shared secret (no onchain trace), while constrained delivery fails, since every sound constrained secret must be backed by an onchain handshake, which needs a wallet. Privacy is therefore never weakened without the wallet opting in.

TXE has no hooks, so tests configure the strategy through a test environment option (unset by default, which exercises PXE's default):

TestEnvironmentOptions::new().with_tagging_secret_strategy(TaggingSecretStrategy::non_interactive_handshake())

Docs: an Execution hooks page documents the hook mechanism and both hooks, the note delivery page gains a Tagging secret strategy section, and the note discovery page is updated.

Fixes F-699

[Thunkar]

I like it!

[vezenovm]

Mostly nits, but one main comment related to failing when the execution hook is incompatible with the delivery mode.

[vezenovm]

Nice!