rs-platform-wallet-storage: persist provider_key_account_registrations (BLS/EdDSA provider-key accounts) #4113

Expected Behavior

rs-platform-wallet-storage's SQLite persister should durably store PlatformWalletChangeSet::provider_key_account_registrations (added in #4072) — the BLS operator-key account and EdDSA platform-node-key account, including the EdDSA entry's pre-derived derived_platform_node_keys list — so a "Node Keys"-style screen could eventually list them from persistence without re-deriving from the seed/mnemonic.

Current Behavior

versions.rs::touched_domains exhaustively destructures PlatformWalletChangeSet (the R8 forgotten-domain guard) and explicitly ignores provider_key_account_registrations with a TODO comment. The field is never mapped to a Domain, never written to any table, and is silently dropped on every store() round. No regression versus prior behavior — rs-platform-wallet-storage (#3968) is a new crate and this field didn't exist before it landed — but it is a real, live data path (bls/eddsa are default-on features), not a dead one.

Possible Solution

Two viable shapes were scoped during #3968 → v4.1-dev merge triage (see PR #3968 discussion for full context):

• (A) Map into the existing Domain::AccountRegistrations family. Upstream's own FFI (rs-platform-wallet-ffi/src/persistence.rs::build_account_specs_for_callback) already merges account_registrations and provider_key_account_registrations into one flat spec array through a single callback, which favors this framing. Still needs new schema: the existing account_registrations table stores a secp256k1-only ExtendedPubKey blob (doesn't fit BLS/EdDSA ProviderKeyExtendedPubKey), and derived_platform_node_keys is a one-to-many list with no existing column to land in — needs a new child table regardless.
• (B) Stand up a dedicated Domain::ProviderKeyAccounts with its own migration, writer, and reader(s). Cleaner separation, more new surface; Domain::ALL grows from 13 to 14.

Either way: new migration (V004+), updated schema-pin tests (sqlite_schema_pinning.rs, sqlite_version_bump.rs), updated Domain::ALL coverage if (B).

Alternatives Considered

Investigated whether dash-evo-tool (the actual consumer) already needs this — it does not. PR dashpay/dash-evo-tool#882 and the wider dash-evo-tool codebase have no "Node Keys" screen and no BLS/EdDSA HD-derivation flow; masternode operator/voting/owner keys are entered manually today (src/ui/masternodes/load_form.rs: "No auto-derive: masternode keys never live in a wallet's HD tree"). dash-evo-tool's Cargo.lock is also pinned to a platform commit that predates ProviderKeyAccountEntry entirely, so it can't reference the type yet. Deferring is safe: nothing downstream is blocked on this landing.

Additional Context

Surfaced during the #3968 (feat/platform-wallet-storage-rehydration) merge with v4.1-dev: the merge itself doesn't conflict textually, but versions.rs's exhaustive destructure turns the new upstream field into a compile error until it's explicitly handled — exactly what that guard is for. Revisit once dash-evo-tool grows an actual provider-key / Node Keys consumer.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}