platform-wallet: expose masternode PoSe validity/score via a public API

[Claudius-Maginificent]

User Story

As a Platform-wallet-integrating app developer (e.g., Dash Evo Tool), I want to query a masternode's real Proof-of-Service (PoSe) status — valid, penalized, or banned — through platform-wallet's public API, so that I can show my users an accurate, real-time masternode health indicator instead of an unrelated proxy signal.

Expected Behavior

platform-wallet (or the dash-spv client it wraps) exposes a public, documented way for a consuming application to query, for a given ProTxHash:

• At minimum: the boolean PoSe-validity flag (is_valid) already tracked internally by the synced masternode list, so a consumer can tell "valid" apart from "PoSe-banned" for masternodes it cares about.
• Ideally: a graduated PoSe penalty/score value, so a consumer can also tell "healthy" apart from "penalized but not yet banned" — see Current Behavior for why this half is harder.

Current Behavior

• platform-wallet's SpvRuntime (packages/rs-platform-wallet/src/spv/runtime.rs) already reaches the synced masternode list internally via dash_spv::Client::masternode_list_engine(), but only for its own peer-connectivity bookkeeping — the result isn't surfaced through any public API. A consuming app currently has no way to read is_valid (or anything else about a specific masternode) through platform-wallet.
• The underlying dash-spv/dash (rust-dashcore) types do carry a per-masternode is_valid: bool field (MasternodeListEntry, in the dash crate's sml::masternode_list_entry module) — the binary "not PoSe-banned" flag from the DIP3 simplified-masternode-list-diff format. It's genuine PoSe-derived data, just not exposed past platform-wallet's internal use today.
• No numeric PoSe penalty/score exists anywhere in that SML diff format — it's only present in Core's full deterministic-MN-list RPC output (protx / masternode list), which is out of reach for an SPV-only client (see Alternatives Considered).
• Related prior request: Support query for masternode via (D)API #2036 ("Support query for masternode via (D)API", closed/stale) asked for something similar via a DAPI extension. This request is scoped to platform-wallet's existing SPV client instead, since that's the dependency our app already has wired in — but a DAPI-based path would satisfy the same underlying need if that's a better fit on the Platform side.

Possible Solution

• Smallest version: a public accessor on platform-wallet's wallet/manager type, e.g. masternode_pose_valid(pro_tx_hash: ProTxHash) -> Option<bool>, or a read-only handle to the synced MasternodeList (BTreeMap<ProTxHash, QualifiedMasternodeListEntry>) — backed by the masternode_list_engine() handle platform-wallet already holds.
• Fuller version: the graduated PoSe score would need either a DAPI endpoint (reviving/repurposing Support query for masternode via (D)API #2036) or some other data source reachable without a trusted local Core RPC connection — flagging this as an open design question rather than prescribing a mechanism, since we don't know what's feasible on the Platform side.

Alternatives Considered

• Querying Dash Core's RPC directly (protx info / masternode list) from the consuming app. Rejected: requires a trusted local dashd connection, which defeats the point of an SPV-based wallet client — and our app (Dash Evo Tool) is moving away from depending on a local Core RPC connection at all.
• Talking to dash-spv directly, bypassing platform-wallet. Possible in principle (the underlying MasternodeListEngine API is public in dash-spv/dash), but our app depends on platform-wallet for wallet/SPV orchestration and doesn't otherwise hold its own dash_spv::Client handle — duplicating that wiring just to reach this one field feels like the wrong layer for it to live at.

Additional Context

This came out of a user-facing UX review in Dash Evo Tool. Our masternode detail screen shows a status dot that today only reflects "does this masternode's Platform identity still resolve" — which users read as "is my masternode healthy on the network." Those aren't the same thing: a masternode that's PoSe-banned (or removed from the masternode list entirely) can still show green. We'd like to show the real signal instead, but currently have no way to reach it through the SPV stack we already depend on.

Filed at the request of a Dash Evo Tool user, following an investigation into the app's masternode status indicator.

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