feat: TON family support (ton, ton-testnet)

[artemrootman]

What

Adds the TON blockchain family (BlockchainType = "ton") — a REST family with the chain's real two-API split: the toncenter v2 HTTP API on the primary rest connector (base URL carries /api/v2) and the v3 indexer on rest-additional, routed statically by the method specs (58 methods: 31 v2 + 27 v3; upstreams without a v3 connector never advertise v3 methods).

Design doc: docs/superpowers/specs/2026-07-17-ton-support-design.md.

Stacked on #285 (starknet family); will retarget as the stack merges.

How

• ton_specific: poll head via getMasterchainInfo (last.seqno + base64 root_hash); the masterchain is BFT-final, so latest == finalized. EmptyHash parent instead of dshackle's random-string hack.
• Race-free chain validation: compares the network zerostate hashes from getMasterchainInfo.init — one call, immune to the tonlib masterchain-ref race that forced dshackle to ship disable_upstream_validation for ton. Testnet zerostate verified against the public endpoint.
• Liveness health validation (dshackle has none for ton).
• ton_labels: client type/version from the v2 openapi.json (TON HTTP API C++ → ton-http-api-cpp).
• ton_bounds: verified-archive probe (lookupBlock seqno=1, generous timeout); non-archival liteservers report an honest UnknownBound, and a not-in-db answer clears any stale cached bound.
• No envelope surgery needed: v2's {"ok":false,"error":...,"code":N} errors arrive as non-2xx with a structured body the existing REST error parsing already understands, and bodies pass to clients byte-exact with status parity.

Testing

• Unit tests across all new packages (incl. testnet-zerostate cross-check and the not-in-db cache-clearing bound path).
• Live corpus against the production mainnet node: 27/27 identical (v2 compared modulo the volatile @extra field), including HTTP-status parity on all error passthroughs and the v3 empty-200 semantics. Details in the design doc.