bug: METRICS_DENYLIST does not prevent query execution or DO creation

## Summary

`METRICS_DENYLIST` is documented as "Comma-separated list of metrics to exclude" but it only filters the **Prometheus text output** — it does not prevent the underlying Durable Objects from being created, fetching data from the Cloudflare API, or attempting to persist state to storage.

Users reasonably expect that adding a query name like `colo-metrics` to `METRICS_DENYLIST` would skip that query entirely. It does not.

## Current behaviour

Setting `METRICS_DENYLIST=colo-metrics,load-balancer-metrics`:

- ✅ Hides those metric names from `/metrics` Prometheus output
- ❌ Still creates DOs for those queries
- ❌ Still calls the Cloudflare GraphQL API for those queries every refresh cycle
- ❌ Still attempts `ctx.storage.put()` which fails with `SQLITE_TOOBIG` (see issue #24)

Logs with `METRICS_DENYLIST=colo-metrics,load-balancer-metrics` still show:

```
{"namespace":"account::colo-metrics","level":"error","msg":"Refresh failed","error":"string or blob too big: SQLITE_TOOBIG"}
{"namespace":"account::load-balancer-metrics","level":"error","msg":"Refresh failed","error":"string or blob too big: SQLITE_TOOBIG"}
```

## Expected behaviour

When a **query name** (e.g. `colo-metrics`, `load-balancer-metrics`) is listed in `METRICS_DENYLIST`, the corresponding DO should not be created and no API calls should be made for that query. This would make `METRICS_DENYLIST` useful for:

- Reducing API quota usage
- Skipping queries the account has no access to (e.g. `magic-transit-traffic`, `network-analytics`)
- Working around the `SQLITE_TOOBIG` crash in local dev mode

## Suggested fix

PR #23 implements this by checking `metricsDenylist` inside `getActiveAccountQueries()` and `getActiveZoneQueries()` before any DO is created. Metric-name filtering at output time is preserved — the two behaviours compose.

## Documentation gap

The README description of `METRICS_DENYLIST` should clarify whether it accepts metric names, query names, or both, and what effect each has.

Review PR #23 and the getActiveAccountQueries() and getActiveZoneQueries() entry points first. Verify the denylist behavior before Durable Object creation and API calls, preserve output filtering, and update the README to distinguish metric names from query names and explain their effects.

Written by the indexing model from the issue text.