feat(pxe)!: unify sender/secret registration into TaggingSecretSource

[nchamo]

Motivation

#23708 added registerSharedSecret/removeSharedSecret alongside the existing registerSender/getSenders/removeSender. Both feed the same machinery (sources from which PXE derives the app-siloed tagging secrets it scans for to discover incoming private logs), but the PXE API presented them as two unrelated method families, even though they're already backed by one store (TaggingSecretSourcesStore). This unifies the public surface.

The change

Replaces the five methods with three over a discriminated union TaggingSecretSource:

• registerTaggingSecretSource(source)
• removeTaggingSecretSource(source)
• getTaggingSecretSources(), which returns every registered source

TaggingSecretSource has two variants:

• { kind: 'sender'; address }: an external address; PXE derives a shared secret via ECDH against every account (present and future). Senders can't be reduced to stored points, so they stay address-anchored.
• { kind: 'arbitrary-secret'; recipient; secret }: a directly-provided shared-secret point scoped to a recipient. A future handshake-secret variant slots in here.

Scoped to PXE: the Wallet interface, address book, CLI, and RPC schema are unchanged; the wallet implementations just call the new methods. A migration entry is added to migration_notes.md.

[nchamo]

Names are meant to be similar to the ones introduced for the sender in #24040

The idea is we will soon add a way to register interactive handshakes for the recipient this way too

[vezenovm]

Suggested change

	expect(remaining).not.toContainEqual(senderSource);
	expect(remaining).not.toContainEqual(secretSource);
	expect(remaining).toEqual([]);

nit: can we not just do this

[nchamo]

Sadly no. Only one PXE is shared among all tests (mostly because it's expansive to create one), so we can only test contains/not contains