Tooling to identify and reap unused deployed subgraphs on Goldsky

[thedavidmeister]

Each deployed subgraph (per network, per version) accrues Goldsky cost. Today there is no signal for which deployed subgraphs are actually being queried by consumers vs. dangling from old deploys.

We need:

• A way to enumerate every `metaboard`-named subgraph currently deployed on Goldsky (across all networks).
• Per-deployment usage stats (queries / bandwidth / last-query timestamp). Goldsky exposes per-subgraph metrics via its API and dashboard.
• A reaping path: a list (or automated script) of subgraphs whose usage is below some threshold for some window, suitable for `goldsky subgraph delete`.

Trigger / context:

• The deploy CI's idempotency check (PR Use deterministic subgraph deploy from updated rainix #99) skips already-deployed versions by name, but does not delete superseded ones. Old contract-address-+-commit-hash slots stay live.
• Consumers can be wrong about the subgraph URL they query (Logic in rain.metadata crate for validating a remote metaboard subgraph against the hardcoded schema and a rain.orderbook CLI command to do the same for a given metaboard in a settings.yml or .rain order file #58 surfaces one mismatch class). An unused-subgraph report is the dual of that — confirming nothing is calling versions we plan to retire.

Possible shapes:

• A new `rain-metadata` CLI subcommand (`subgraphs report`) that hits Goldsky's API and prints a usage table.
• A scheduled GHA that runs the report and posts to an issue / Slack weekly.

[thedavidmeister]

Ormi may consider pre-query pricing as a path to migrating away from Goldsky. The arrangement would be custom, so we need to go over the details with them. Then we have to verify the resulting cost actually beats Goldsky before committing to a migration.