fix: dashboard reads from configured Analytics Engine dataset name

[rbonestell]

Overview

Dashboards showed 0 sites and no analytics data for any install that customized the Cloudflare Analytics Engine dataset name via npx @counterscale/cli install --advanced. The tracker correctly wrote to the user-chosen dataset (through the WEB_COUNTER_AE binding), but every SQL query in the dashboard read path had FROM metricsDataset hardcoded, so reads always hit the default dataset, regardless of what the binding pointed at.

This PR threads the dataset name end-to-end via a new CF_DATASET_NAME Worker var so the read path always matches the binding. Default-name installs continue to work with no migration required.

Changes by Package

@counterscale/cli

• stageDeployConfig now writes vars.CF_DATASET_NAME into the generated wrangler.json alongside the existing analytics_engine_datasets[0].dataset, sourced from the same analyticsDataset value so the two fields can't drift on a fresh install.
• Added DATASET_NAME_PATTERN (/^[A-Za-z0-9_]+$/) and validate the dataset name in stageDeployConfig, so invalid input fails at install time with a clear error instead of at Worker boot.
• --advanced install now prints a warning before prompting, reminding upgraders to re-enter their previous custom worker name and dataset to avoid silently repointing their deployment at a fresh, empty dataset.
• Updated config.test.ts placeholder values from "new-dataset" (hyphenated, not a valid CF AE identifier) to "newDataset", and added an assertion that writtenConfig.vars.CF_DATASET_NAME matches the dataset binding.

@counterscale/server

• AnalyticsEngineAPI now takes an optional dataset constructor argument (exported as DEFAULT_DATASET_NAME = "metricsDataset"), validated against the same regex as the CLI, with safe fallback on empty/undefined.
• All 7 occurrences of FROM metricsDataset in query.ts replaced with FROM ${this.dataset}.
• load-context.ts passes env.CF_DATASET_NAME into the constructor; default handling stays in one place (the ctor).
• Scheduled handler (workers/app.ts) forwards env.CF_DATASET_NAME into extractAsArrow, which in turn forwards it to the inner AnalyticsEngineAPI so the daily R2 rollup also reads from the correct dataset.
• The standalone debug IIFE at the bottom of workers/lib/arrow.ts now reads process.env.CF_DATASET_NAME so manual script runs respect the configured dataset.
• Added CF_DATASET_NAME to wrangler.json vars (defaulted to "metricsDataset"), worker-configuration.d.ts (matches what wrangler types regenerates from vars), and .dev.vars.example.
• Added 5 new tests in query.test.ts covering: default behavior, empty-string fallback, custom-name pass-through, invalid-name rejection, and an end-to-end assertion that getCounts emits FROM counterscaleMetrics (not metricsDataset) when constructed with a custom dataset.

@counterscale/tracker

No changes, the tracker writes through the WEB_COUNTER_AE binding, which already respected the user's chosen dataset. The bug was strictly on the read path.

Other Changes

None.

Additional Notes

• Backward compatibility: Existing installs on the default metricsDataset continue to work without redeploy because DEFAULT_DATASET_NAME is "metricsDataset" and the constructor falls back to it when the var is absent. A redeploy via the updated CLI will additionally populate vars.CF_DATASET_NAME to make this explicit.

• For affected users (custom dataset): Re-running npx @counterscale/cli install --advanced with the new CLI version and entering the same custom dataset name they originally chose will restore their dashboard. The newly added warning at the top of the advanced prompt calls this out.

• Why duplicate the dataset name (binding dataset + vars.CF_DATASET_NAME)? Worker JS only sees the binding as an opaque AnalyticsEngineDataset handle exposing writeDataPoint, there is no way to read the bound dataset's string at runtime. The dashboard's read path uses the Analytics Engine SQL API over HTTPS and needs the literal name in FROM <dataset>, so it has to come from a var. The CLI writes both fields from the same source value so they're guaranteed consistent on install.

• Out of scope / follow-up candidates:

  • The CLI does not persist install-time choices anywhere on disk (a wrangler.json is never written, the staging config lives in a tmp dir that's removed on exit). This means the advanced-install prompt can't auto-default to a user's previously chosen dataset name. Mitigated here by a user-facing warning; a proper fix could introduce a small state file and is a candidate for a separate PR.

Resolves #248