PUBLIC_RPCS.POLYGON_AMOY primary RPC host does not resolve

`PUBLIC_RPCS.POLYGON_AMOY` (`lib/rpc/rpc-config.ts:56`) is `https://rpc-amoy.polygon.technology`, and that hostname does not resolve. Two independent vantage points return NXDOMAIN for it; the configured fallback `polygon-amoy-bor-rpc.publicnode.com` (`:57`) resolves normally.

It is the `publicDefault` for chain 80002 (`:193`), so it is the primary any install without `CHAIN_POLYGON_AMOY_PRIMARY_RPC` set resolves to, and `scripts/seed/seed-chains.ts` writes the resolved value into the chains table. A self-hosted or unconfigured install therefore seeds a non-resolving primary for Amoy and reaches the network only via failover to the fallback.

Impact is bounded - the fallback works, so Amoy is not down, it is running one failover deep on every call, with the primary's DNS failure paid as latency on each attempt.

Two things to settle:
- Whether Polygon has retired that host permanently, in which case the entry should be replaced rather than reordered.
- Whether anything else in `PUBLIC_RPCS` has gone the same way unnoticed. Nothing checks these hosts, which is why this surfaced only when someone probed them by hand.

Credit: found by @tenk-earn while surveying trace-method availability in #2273, recorded there as a table cell. Filing it separately because it is a live configuration defect rather than a trace question.

Start with lib/rpc/rpc-config.ts at lines 56, 57, and 193, then inspect scripts/seed/seed-chains.ts to understand how the primary RPC is stored. Verify the Amoy hostname and survey the other PUBLIC_RPCS entries for similar DNS failures. Done means the Amoy primary configuration reflects the confirmed provider status and the seed path no longer records a non-resolving primary.

Written by the indexing model from the issue text.