fix(scroll-sepolia): drop dead RPC and Blockscout API endpoints

[cargopete]

Two endpoints in registry/eip155/scroll-sepolia.json no longer exist. Reported by
@yash251 (Edge & Node) as "Scroll Sepolia network disappeared", which turned out not to be
the case: the chain is fine and the registry entry is stale.

The chain is alive

The two remaining rpcUrls both answer and agree, measured 2026-08-11:

Endpoint	Result
https://sepolia-rpc.scroll.io	HTTP 404, {"code":-32055,"message":"No nodes available"}
https://scroll-sepolia.drpc.org	200, block 0x1228645
https://scroll-sepolia-public.nodies.app	200, block 0x1228645

0x1228645 is block 19,039,813, returned independently by both. Scroll Mainnet answers
too, so this is not a Scroll-wide outage.

What this PR removes

https://sepolia-rpc.scroll.io from rpcUrls. Scroll's own public endpoint resolves
and serves, and replies "No nodes available" — its gateway reporting that it has no
backends left for this network, rather than a timeout or a blip. It is currently listed
first, so anything that takes the first entry and trusts it concludes the network is gone.

https://scroll-sepolia.blockscout.com/api from apiUrls. Returns a bare
404 default backend. The mainnet sibling scroll.blockscout.com still resolves, so the
Sepolia instance specifically has been retired. sepolia-blockscout.scroll.io now
redirects to Scrollscan.

The remaining https://scroll-sepolia.abi.thegraph.com/api was checked and behaves
identically to its mainnet counterpart, so the entry is not left without an API endpoint
and no new has no API endpoints warning is introduced.

Deliberately not changed

explorerUrls still lists https://sepolia.scrollscan.com, which currently returns 403.
That is worth a maintainer decision rather than a silent deletion, because Scrollscan is the
only explorer Scroll points at for this network.

Worth noting the 403 is not anti-bot noise. Etherscan-family sites block non-browser clients
routinely, so we ran the control: with an identical browser user-agent, mainnet
scrollscan.com returns 200 while sepolia.scrollscan.com still returns 403. Same operator,
same request shape, different answer. Whether that is deliberate deprecation or a
misconfiguration is a question for Scroll, who have been asked in both their Slack and their
Discord without reply so far.

Validation

bun validate passes with zero errors. The 14 warnings are pre-existing and none concern
scroll-sepolia. bun format:check clean. No version bump, per AGENTS.md.

Full investigation: nightswatchhq/graph-support#16