feat: fund an identity asset lock from the wallet's own Core outputs

[LexxXell]

Funds an identity asset lock from the wallet's own Core outputs, so registering or topping
up an identity no longer needs a deposit address. The caller picks the output.

Pipeline

Before: REQUEST_ASSET_LOCK_FUNDING_ADDRESS hands out a one-off address whose key is
stored encrypted, the user deposits coins to it, and REGISTER_IDENTITY /
TOP_UP_IDENTITY spend that deposit.

Now: LIST_CORE_UTXOS lists the account's spendable outputs by xpub, the frontend picks
one (coin control), and the same two calls take that output's address and txid in the
fields they already had. The deposit path is untouched: when the address has a record in
AssetLockFundingAddressesRepository, develop's branch runs as before.

What this adds

• LIST_CORE_UTXOS, the only new messaging method. Payload shapes of the two identity
  calls are unchanged.
• CoreExplorerService.getXpubUtxos, a paged POST /xpub/utxo.
• CoreExplorerService.getOutputSpender, a single GET /transaction/<txid> that reads
  vOut[].spentTxId for the output paying the funding address.
• deriveCoreAddressPrivateKey: finds the address among the account's BIP44 addresses,
  bounded by the explorer's own gap scan, and refuses an address the wallet does not own
  before any derivation or broadcast happens.

Nothing new is stored. A registration retry needs the identity index the committed asset
lock funded, and a top-up retry needs the DIP-13 index that owns its credit output; with
no record to read, both come from L1: the funding output names the transaction that spent
it, and that txid selects the index, through develop's existing
recoverIdentityIndexFromTxid for registration and the same rebuild-and-compare for a
top-up. The credit output still lands on a DIP-13 key
(m/9'/coin'/5'/1'/index for registration, .../2'/index for a top-up), so a wallet
restored from the seed finds the credits.

The storage schema, the funding-address repository and every other handler are untouched.

Testnet run

Extension funded with one output of 100000000 duffs, identity already present so the
scenario took the top-up branch. Seven checks, all passed:

• the wallet lists its own spendable outputs
• an address that is not the wallet's own is refused, before any key work
• a wrong password is refused
• the identity was topped up, 4 s from the call to the result
• the chosen output was spent, and only that one
• the wallet still holds the same identity
• repeating the finished call does not spend a second time

Identity 2HPEBQW4JgatyogjFc5KdYzAXaPAyTEG4ShYYKS7w643, state transition
0b4c0c3682f34b0df9a382edb455008232c4b6573c208ce3e1fbc26e6acc0059, funding transaction
a6b83e298644b3e608a5cced2be0bae5ccef8088924a2b39ef9481f32a00d695.

Diff: 368 added and 73 removed lines of source across 9 files, plus tests. Unit tests pass
except for the live-network identity import suites, which fail intermittently with
fetch failed on this branch and on develop alike.

Separate defect, not fixed here

SWITCH_NETWORK re-points DashPlatformSDK only. DashCoreSDK has no network setter, and
the offscreen backend builds it once at startup, so after a network switch the core SDK
stays on the previous network until the extension is reloaded. TOP_UP_IDENTITY catches
this in its scope guard before signing or broadcasting; REGISTER_IDENTITY has no such
guard and would talk to DAPI on the wrong network. Proposed one-method fix in its own PR:
PrivateAPI.setNetwork() rebuilds coreSDK and calls buildHandlers(), and
SwitchNetworkHandler calls it instead of sdk.setNetwork(). No new messaging method, no
frontend change.