explorer: 2D hardware museum + miner history endpoints

[liu971227-sys]

Implements rustchain-bounties#29 Phase 1 (2D museum + explorer fixes).

• Adds /museum 2D UI (cards + filters + arch mix + first-attest timeline + detail modal)
• Adds /api/miner//attestations (best-effort; 404 if table missing)
• Adds /api/balances (schema-flexible) to satisfy explorer expectations
• Enhances /api/miners to include first_attest (best-effort)
• Adds museum links into /explorer

Miner ID: liu971227-sys

[David-code-tang]

Security-focused review (PR #148)

1. New public endpoints expand data exposure

• /api/balances returns a leaderboard of balances up to limit=5000.
• /api/miner/<miner_id>/attestations returns historical attestation timestamps.
  If the project wants these public (explorer use-case), that’s fine, but it’s worth explicitly acknowledging this as a privacy surface (wallet activity + rankings) and adding rate-limits / caching to reduce scraping/DoS.

2. Input validation: limit = int(...) can 500 on bad input

• Both endpoints do int(request.args.get('limit', ...)) without guarding ValueError.
• A request like ?limit=abc will raise and return 500.
  Suggestion: wrap in try/except and default to a safe value.

3. DoS considerations

• /api/balances allows up to 5000 rows; that’s potentially heavy on slower disks/large DBs.
  Suggestions:
  • keep a smaller default (e.g. 500) and require explicit larger limits.
  • add server-side caching (in-memory TTL) for this endpoint.

4. Static assets route

• /museum/assets/<path:filename> uses send_from_directory, which is generally safe against traversal.
• The route does compute root = abspath(join(dirname(__file__), '..')); please ensure the museum directory resolves exactly to .../web/museum and avoid ever allowing user-controlled root.

5. BOM/encoding

• web/museum/museum.css begins with a UTF-8 BOM (shows as +:root{). This can cause odd rendering/tooling issues.
  Suggestion: remove BOM.

Overall: great feature; biggest security question is whether /api/balances is intended to be publicly enumerable and how you want to mitigate scraping.

[David-code-tang]

Security review notes (museum/explorer UI):

1. DOM XSS sinks via innerHTML with untrusted miner metadata:

• web/museum/museum.js: legend.innerHTML uses where n is derived from device_family/device_arch from /api/miners. If an attacker can attest with a crafted string containing HTML, this becomes stored XSS.
• web/museum/museum3d.js: kv.innerHTML renders miner + other fields directly into HTML.
• The el() helper supports {html: ...} which is easy to misuse later.

Suggested fix: avoid innerHTML for any field that can be influenced by miners; use textContent/text nodes (or at minimum a small escapeHtml() and apply it before constructing HTML).

2. UTF-8 BOMs in new web assets
   Diff shows a BOM at start of several new files (e.g. museum.js / museum3d.*). Recommend removing; we’ve seen this cause garbled UI strings and tooling issues elsewhere.

Nice work overall on keeping most rendering via DOM nodes + textContent; tightening the few remaining innerHTMLs should make this safer.

[Scottcjn]

Changes Requested — Fun concept, needs testing

A 2D hardware museum for the block explorer is creative and fits our vintage computing ethos. However:

1. Test evidence needed: Include a screenshot of the museum rendering with actual miner data
2. API endpoints: The miner history endpoints need to work with our existing database schema. Verify field names match miner_attest_recent table columns
3. Performance: Loading all historical miner data could be slow — add pagination or limit to recent epochs
4. Static assets: Where do the 2D sprites/assets come from? Include them in the PR or document the source

Address these and we'll review again.