[High] Build a public proof-of-reserves dashboard reconciling solver bonds against `SECURITY.md`'s Assets-at-Risk table

[james2177]

Description: Build a public, continuously-updated dashboard that reconciles on-chain-observable solver bond totals (and, once implemented, treasury balances per issue #37) against SECURITY.md's own Assets-at-Risk table, giving the community an ongoing, verifiable answer to "is the collateral this protocol's security model depends on actually present" — a proof-of-reserves-style transparency tool distinct from issue #40's dashboard (which tracks pending governance proposals, not fund reconciliation).

Problem Statement & Context: SECURITY.md's Assets at Risk table states solver bonds are "≥ 50 USDC per solver" and treats bond size as "the primary economic deterrent" against solver default — but today, verifying that solvers' aggregate posted collateral genuinely matches what the protocol's economic security assumptions require means manually enumerating solvers and summing get_solver(address).bond_amount calls, exactly the gap docs/110-monitoring-alerting-spec.md's §3.2 flags: "There is currently no view that sums bonded collateral across all registered solvers in one call." Once issue #46 ships a TotalBonded aggregate counter, the raw data exists on-chain — but nothing yet presents it as an ongoing, public, trust-building artifact the way "proof of reserves" dashboards do for custodial platforms.

Scope & Acceptance Criteria:

• A public dashboard (a static site regenerated periodically, or a small live page) displaying: total bonded collateral (via issue Design solver_registry contract: tiered staking with reputation scores #46's TotalBonded counter, or computed via enumeration if that issue hasn't landed), total open-intent notional volume at risk, and — once issue Document the DstAllowlistEnabled-off-by-default decision for mainnet launch #37 ships — treasury balance, each clearly labeled against the specific SECURITY.md Asset-at-Risk row it corresponds to.
• The dashboard's data source is documented and independently reproducible (e.g., "these numbers come from calling get_protocol_health/get_stats/TotalBonded against <CONTRACT_ID> on <NETWORK>, refreshed every N minutes") so it's a verification tool, not a black box the community has to trust blindly.
• Out of scope: any claim of "insurance" or guarantee beyond what's actually true on-chain (e.g., this dashboard must not imply user funds are protected beyond what SECURITY.md's own threat model already honestly states) — accuracy and honesty about the limits of what bond collateral actually backs is a hard requirement, not a nice-to-have.

Implementation Guidelines:

1. Key files: SECURITY.md (Assets at Risk table — the exact structure this dashboard's sections should mirror), intent_settlement/src/lib.rs (get_protocol_health, get_stats, and issue Design solver_registry contract: tiered staking with reputation scores #46's TotalBonded counter once it lands), indexer/reference-indexer.js (a natural data-fetching base to build on, consistent with how issue Surface cargo-audit CI results as a step summary rather than pass/fail only #104's monitoring tool and issue Add reentrancy-focused tests using a hostile mock SEP-41 token #40's proposal dashboard both anchor to it).
2. If issue Design solver_registry contract: tiered staking with reputation scores #46's TotalBonded counter hasn't landed yet, fall back to enumeration via issue feat: get_bond_token view #13's solver-listing view (once that lands) or event replay, and clearly document the fallback's potential staleness/incompleteness versus the eventual first-class counter.
3. Edge cases: a solver that has deregistered but whose bond is mid-withdrawal, or an intent that's PartiallyFilled with tokens already delivered but the intent not yet closed, both need clear, documented treatment in what counts as "at risk" versus already-settled — get this distinction right rather than producing a number that looks precise but double-counts or omits a real state.
4. Testing: minimum coverage — the dashboard's computed totals verified by hand against a small number of manually-queried solver/intent records on testnet, and a regression check that the published numbers update correctly after a real (testnet) bond change.

Definition of Done:

• Code written, tested, documented; linked from README.md and SECURITY.md.
• Acceptance criteria met.
• PR passes CI (or includes a documented manual verification if the dashboard is a static-site build without a traditional test suite), includes example output.
• Reviewed and approved.

Resources: SECURITY.md, intent_settlement/src/lib.rs (get_protocol_health, get_stats), docs/110-monitoring-alerting-spec.md, indexer/reference-indexer.js

Complexity: High (200 points)