fix(cloudflare): correct TPR's zone-analytics query and export its selection helpers

[kHorozhanov]

What

Two changes to @vinext/cloudflare's TPR module:

1. Fix the zone-analytics query — it cannot succeed as written, so --experimental-tpr silently pre-renders nothing.
2. Export the traffic-selection helpers, so ranked route selection can be reused with the already-public warmCdnCache.

The bug

queryTraffic asks httpRequestsAdaptiveGroups for orderBy: [sum_requests_DESC] and selects sum { requests }. Neither exists on that dataset. Verified against a live zone:

query	result
orderBy: [sum_requests_DESC] + sum { requests }	error parsing args … orderBy: unknown enum value sum_requests_DESC
orderBy: [count_DESC] + sum { requests }	unknown field "requests"
orderBy: [count_DESC] + count	✅ returns rows

These are schema-validation failures, not plan gating — contrast a genuinely plan-gated field like edgeResponseContentTypeName, which fails with code: authz ("does not have access to the field"). So the query fails on every zone regardless of plan.

Why it went unnoticed: runTPR catches a failing traffic query and treats it as "no traffic data", then skips gracefully — which is indistinguishable from a zone that genuinely has no traffic. The feature reports success and does nothing.

Fixed by using count_DESC / count, and mapping g.count instead of g.sum.requests.

Tests

tests/tpr-traffic-query.test.ts is new — there was no coverage of queryTraffic at all (only tpr-kv-keys.test.ts, which covers the KV key format). It pins the parts of the request the schema actually validates, the response mapping, and error surfacing. I verified the guard fails on the old query and passes on the new one:

AssertionError: expected '{\n    viewer {\n      zones(filter: …' to contain 'orderBy: [count_DESC]'

It also covers filterTrafficPaths and selectRoutes, which were previously untested.

The export

warmCdnCache is already exported from @vinext/cloudflare/internal/cdn-warm and takes an arbitrary targetUrl + paths, which makes it usable outside the bundled deploy pipeline — useful when the deployment shape isn't the one vinext-cloudflare deploy builds (in our case a gateway worker in front of the renderer, so warming has to go through the gateway URL). But it has no way to decide which paths to warm, and the logic for that already exists here.

So this exports queryTraffic, filterTrafficPaths, selectRoutes and resolveZoneId (plus the TrafficEntry / SelectedRoutes types) from @vinext/cloudflare/internal/tpr, following the same precedent that made cdn-warm a separate entry point. No behaviour change — the only public entry today is runTPR, which also does the local pre-render and KV upload.

One thing worth flagging for anyone reusing filterTrafficPaths: it assumes zone == one app. On a zone shared by several Workers the raw top paths include the other Workers' routes, which callers need to filter by their own base path.