fix: correct Magic Transit tunnel health metrics (active dimension, resultStatus)

[michielappelman]

Problem

cloudflare_magic_transit_active_tunnels, cloudflare_magic_transit_healthy_tunnels, and cloudflare_magic_transit_tunnel_failures were missing or wrong for accounts with active Magic Transit tunnels, even though the underlying GraphQL data clearly existed and the API token had correct permissions.

Root-caused via direct GraphQL testing against a live account with both GRE and CNI/PNI (Cloudflare Network Interconnect) tunnels. Two independent bugs were found (a third, unrelated bug affecting whether these queries ever run at all for zero-zone accounts is split out into #50):

1. The active dimension breaks magicTransitTunnelHealthChecksAdaptiveGroups

Including active in the dimensions selection set causes the query to return zero rows, for every time window tested (60s through 13h), regardless of tunnel type:

Connection type	Rows without active	Rows with active
GRE tunnel	719	0
CNI/PNI interconnect	716	0

Verified via raw curl against /client/v4/graphql with no exporter code involved, and reproduced identically on a second, unrelated account. Notably, Cloudflare's own dashboard queries for this exact dataset (captured from the network tab while viewing the Magic Transit tunnel health charts) never select active as a dimension - only tunnelName, resultStatus, and one of datetimeFiveMinutes/remoteTunnelIPv4. This looks like an upstream GraphQL Analytics bug specific to that field; it's being reported separately to the API owners. In the meantime this PR removes active from the query and drops the cloudflare_magic_transit_active_tunnels metric that depended on it, since it can't be computed without the field.

This also explains a confusing support pattern: dashboard graphs for a tunnel can show healthy/active data while this exporter shows nothing at all for the same account/timeframe - the two are querying the same dataset with different dimension sets, and only one of them hits the broken field.

2. resultStatus filter checks for the wrong string

The code filtered on resultStatus === "healthy", but the API never returns that value. Verified across two independent accounts (including a customer's production data) that the actual values are "ok" (success) and "timeout" (failure) - never "healthy".

Effect of the bug:

• cloudflare_magic_transit_healthy_tunnels was permanently empty (the filter never matched).
• cloudflare_magic_transit_tunnel_failures was counting every successful health check as a failure, since its filter was resultStatus !== "healthy", which matched "ok" results too.

Changes

• src/cloudflare/gql/queries.ts: remove active from MagicTransitMetricsQuery dimensions.
• src/cloudflare/client.ts: remove the now-unbuildable cloudflare_magic_transit_active_tunnels metric; fix resultStatus comparisons from "healthy" to "ok".
• README.md: remove the now-removed cloudflare_magic_transit_active_tunnels row from the metrics table.

Testing

• tsc --noEmit and vitest run (56 existing tests) pass.
• biome check clean on all touched files.
• Verified live on a deployed Worker against a real account with 3 Magic Transit tunnels (2x GRE, 1x CNI/PNI, also depended on the fix in fix: don't block account-scoped refresh on zero-zone accounts #50 to get any account-level data at all): before this fix, active-dependent metrics were empty (the active dimension bug) and healthy_tunnels/tunnel_failures were wrong (the resultStatus bug); after, all metrics report correctly, e.g. cloudflare_magic_transit_healthy_tunnels{tunnel_name="..."} 10557 matching real health check volume, and tunnel_failures dropping from ~10590 (incorrectly counting successes) to 1 (actual failures) for the same tunnel/window.

Breaking change

cloudflare_magic_transit_active_tunnels is removed. It cannot be reintroduced until the upstream active field issue is resolved by Cloudflare, since there's no other way to compute it from this dataset today.