feat: index Planck

`a1-planck.quantus.cat` answers, and has all along. The config comment claimed
Planck "publishes no RPC endpoint we can find" — true when written, and never
rechecked after the node we ran for it was switched to mainnet. A million blocks
of history and 2.38M zk-tree leaves were sitting there unasked for.

Measured before committing to it. Three chains backfilling at once cost 4.8% of
one core, five of eight Postgres connections with one active, and no movement in
API latency — summary 7 ms p95, block 13 ms, account 49 ms. The walk is bound by
RPC round trips rather than by anything local, so it needs no deployable of its
own; and `backfill` only reads in-memory state while writing solely to Postgres,
so it contends with nothing the API serves.

Unthrottled deliberately: ~46 hours at roughly 20 requests a second against a
public node. Leaning on public decentralised testnet infrastructure exercises
what it is there for.

Restart resilience confirmed by killing the process mid-walk — `event_scan.low`
stayed put rather than jumping back to the tip. That is load-bearing here rather
than tidy, because the cert-rotation path restarts this service several times a
day and a cursor in memory would mean Planck never finishing.

`a2-planck` answers too, and is noted for when a chain can hold more than one
endpoint.

Closes #6

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jp6a8EDar9ueEhAxzep4V5

asset/config/config.toml.tmpl

@@ -121,11 +121,34 @@ target_block_time_seconds = 6.0
 warm_start_blocks = 100800
 max_gap_fill_blocks = 5000
 
-# Planck, Quantus Staging Mainnet and Quantus Dirac Testnet are listed in the
-# nav from telemetry and are NOT navigable: none publishes an RPC endpoint we
-# can find, and the one node we ran for Planck now mines mainnet. The pattern for the ones that do is `a1-<chain>.quantus.cat` /
-# `a2-<chain>.quantus.cat`; if endpoints appear for those chains, each becomes a
-# [[chains]] block like the two above and nothing else changes.
+[[chains]]
+id = "planck"
+display_name = "Planck"
+genesis = "0x4901bf5c57fd3f9e726af399c763de6670dbdb115a91c0237e173f16eef65e72"
+# Public, and operated by the Quantus team. The node we used to run for Planck
+# now mines mainnet, which is why this entry was absent for a while — the chain
+# was reachable the whole time and nothing here was asking.
+#
+# Backfilling a million blocks is roughly two days at ~20 requests a second
+# against someone else's node, deliberately unthrottled: leaning on public
+# decentralised testnet infrastructure is what it is for. Measured alongside the
+# other two chains it costs about 5% of one core and does not move API latency —
+# the walk is bound by RPC round trips, not by anything here.
+rpc_url = "https://a1-planck.quantus.cat"
+ws_url = "wss://a1-planck.quantus.cat"
+# A testnet, so the nav files it under `TESTNETS` and says its balances are not
+# real. Never inferred from the name — see `mainnet` above.
+target_block_time_seconds = 6.0
+warm_start_blocks = 100800
+max_gap_fill_blocks = 5000
+
+# Quantus Staging Mainnet and Quantus Dirac Testnet are listed in the nav from
+# telemetry and are NOT navigable: neither publishes an RPC endpoint we can
+# find. The pattern for the ones that do is `a1-<chain>.quantus.cat` /
+# `a2-<chain>.quantus.cat` — `a2-planck` answers too, and will be worth having
+# once a chain can hold more than one endpoint. If endpoints appear for those
+# chains, each becomes a [[chains]] block like the three above and nothing else
+# changes.
 #
 # Mainnet launched on 2026-09-09 as telemetry's "Quantus", and is the
 # `[[chains]]` entry above. "Quantus Staging Mainnet" is a different, staging

readme.md

@@ -528,6 +528,25 @@ deliberate exception is a height resolving to its hash, which *replaces* rather
 than pushes — it is the same block under a better name, not a second place the
 reader has been.
 
+## Backfill is cheap, and bound by somebody else's node
+
+Three chains walking their history at once — mainnet, Heisenberg and Planck's
+million blocks — costs about **5% of one core**, holds five of eight Postgres
+connections with one active, and does not move API latency: `summary` at 7 ms
+p95, `block` at 13 ms. The walk is bound by RPC round trips, not by anything
+here, which is why it needs no deployable of its own.
+
+It is also separable if it ever does. `backfill` only *reads* in-memory state —
+the tip height and the current runtime — and writes exclusively to Postgres, so
+it contends with nothing the API serves. Live `ingest` is the half that could
+not move: it feeds the window, the ticker and the attributions that the API
+answers from.
+
+Progress survives a restart because `event_scan` is a table rather than a field.
+That is load-bearing rather than tidy: `blackbeard-api-cert.path` restarts the
+service several times a day when the host certificate rotates, and a cursor in
+memory would mean Planck never finishing.
+
 ## Data
 
 Postgres on `magrathea.kosherinata.internal`, mTLS and passwordless — the host's