fix(chain): refresh DEFAULT_RPC_POOL, drop stale rpc.sentinel.co as primary

[Sentinel-Bluebuilder]

Why

rpc.sentinel.co has been stuck behind tip while still reporting catching_up=false, so it serves stale ABCI bank balances. Apps that pick it as primary (which the latency-first failover does on cold start, since sentinel.co usually answers /status quickly even when its ABCI state is stale) end up reading wallet balances and subscription state that are weeks old.

This is exactly the failure mode captured in findings/2026-04-30-cli-e2e-real-money-report.md (local-only finding, not in this PR), where every broadcast attempt failed against the old 3-entry pool with:

Could not connect to the Sentinel network. We tried these servers and none responded: https://rpc.sentinel.co:443, https://sentinel-mainnet-rpc.autostake.com:443, https://sentinel-rpc.polkachu.com:443.

/status lying about sync state is stronger than a connectivity problem — a node can answer /status instantly while serving ABCI state that is hours/days behind, and there's no way to distinguish from the client without an out-of-band check.

Audit method

For each candidate endpoint:

1. Tendermint37 connect (8s timeout)
2. /status reports catching_up: false
3. ABCI bank balance query for a known funded sent1... address returns the expected amount

Step 3 is the load-bearing one — it catches stale-ABCI nodes that pass /status checks. The full audit script is part of Sentinel-Bluebuilder/blue-js-sdk PR #28 and Sentinel-Bluebuilder/sentinel-node-tester@d34b05a (scripts/audit-rpc-endpoints.mjs).

Refreshed pool (verified 2026-05-02)

Tier	Endpoint	Notes
Primary	https://rpc-sentinel.busurnode.com	sub-200ms
Primary	https://rpc.sentinel.suchnode.net	sub-500ms
Primary	https://sentinel-rpc.publicnode.com	sub-500ms
Primary	https://rpc.trinitystake.io	sub-500ms
Community	https://sentinel-rpc.polkachu.com:443	retained
Community	https://sentinel-mainnet-rpc.autostake.com:443	retained
Community	https://sentinel-rpc.freshstaking.com	added
Stale-fallback	https://rpc.sentinel.co:443	kept LAST so it can still answer if every other endpoint is down, but never picked first

Scope

• src/main/services/chain.ts — replace DEFAULT_RPC_POOL literal, expand JSDoc.
• README.md — update the RPC pool row in the architecture table.

Consumers (src/main/services/deploy.ts, src/main/services/settings.ts) already pull DEFAULT_RPC_POOL through the latency-aware failover, so no other code change is needed.

Test plan

• tests/unit/chain.test.ts — assertions are loose (length >= 3, https:// prefix); both still pass.
• No new dependencies, no behavior change beyond the URL list.
• Latency-aware failover in withFailover (existing) handles ordering at runtime — pool order here is just the seed.
• Reviewer: spot-check that one of the new primaries (e.g. busurnode) answers curl https://rpc-sentinel.busurnode.com/status with catching_up=false and a recent latest_block_time.

Related

• Sentinel-Bluebuilder/blue-js-sdk#28 — same refresh applied to the SDK's RPC_ENDPOINTS defaults.
• Sentinel-Bluebuilder/sentinel-node-tester@d34b05a — same refresh applied to the node tester's core/constants.js.