feat: register an identity from the wallet's shielded pool

[LexxXell]

Draft. Third in the chain: #168 (Core) → #171 (Platform registration) → #172 (Platform top-up) → this one. Until they merge the diff carries their commits and CI fails the same way (calculateMinRequiredFee needs #167).

Changes

The third funding source: an identity created straight out of the wallet's shielded pool, spending its own notes. REGISTER_IDENTITY_FROM_SHIELDED_POOL confirms what PREPARE_IDENTITY_FUNDING quoted with source: 'shielded'.

• shieldedProtocolVersion / shieldedDenominations — the pool creates an identity only at fixed denominations, and which ones depends on the drive protocol (v12 and v13 are supported here). An unknown protocol yields an empty list, which is how a caller learns the source is unavailable rather than by failing later.
• selectShieldedIdentityNotes — covers the denomination largest note first, within the 5-note action limit. A balance spread over more notes than that cannot fund an identity even when the total looks sufficient, and that is said plainly.
• shieldedFallbackAddress — the Platform address the protocol returns the funds to if creation fails. It is the wallet's first Platform address, cached like any other so it can be shown later without the password; an xpub that does not match the seed is never overwritten silently.
• quoteShielded — builds and proves the transition at quote time, then stores it. Proving is the slow part, so a retry sends the stored bytes instead of proving again.
• A shielded registration that executed but created no identity is not retried: the protocol has already returned the denomination to the fallback address, so the operation ends as failed with that address in the message.
• GET_IDENTITY_FUNDING_SOURCES now answers for all three sources. The shielded balance is included only when the request carries a password, since recovering notes needs the viewing key.
• While a shielded funding operation is pending, SEND_SHIELDED_TRANSFER, UNSHIELD_TO_ADDRESS and WITHDRAW_SHIELDED_TO_CORE are refused — they would spend the same notes and leave the proof unusable.
• A shielded top-up is refused up front with a clear message: crediting an existing identity out of the pool needs drive protocol v14, which is not released. It gets its own PR when it is.

The pool read still goes through the shared loadUnspentShieldedNotes helper; it moves into ShieldedService with #170, and this service then calls that instead.

Backend only — no UI changes.

Testing

• tsc --noEmit, ts-standard
• test/api/private/identities/identityFunding.spec.ts — eight new cases: a quote at an allowed denomination stores the proof and a repeat prepare does not prove again; a denomination the protocol does not allow is refused before proving; a shielded top-up is refused with the v14 message; notes spread beyond the action limit are refused; a registration that created no identity ends as failed naming the fallback address; the notes are held against other shielded spends while pending; the sources answer lists denominations and includes the balance only with a password; an unknown protocol reports the source as unsupported.
• jest: 44 suites, 28 cases in the funding spec; the only failures are the network-dependent specs that flake on develop too and pass on a re-run.
• Proving is mocked in the specs — the live run on testnet is the demo, and it is what will confirm the denomination table against the network.

[LexxXell]

Superseded by #177. The funding journal chain is parked on the archive/identityFundingJournal branch.