fix: don't truncate the sites dropdown to 10 entries

[dowands]

Overview

The dashboard's site dropdown is capped at 10 sites. On a deployment with more than 10 active sites, the rest are unreachable from the UI: there is no pagination and no indication that the list is truncated.

The intent is stated in the comment directly above the call site:

// sites by hits: This is to populate the "sites" dropdown. We query the full retention
//                period (90 days) so that any site that has been active in the past 90 days
//                will show up in the dropdown.
const sitesByHits = analyticsEngine.getSitesOrderedByHits(
    `${MAX_RETENTION_DAYS}d`,
);

But getSitesOrderedByHits(interval, limit?) does limit = limit || 10, and this call site doesn't pass one, so the implementation contradicts the stated intent.

The default looks deliberate for the other caller: the no-?site= redirect a few lines up only reads sitesByHits[0], where a small limit is a reasonable way to keep that query cheap. The dropdown was added against the same helper and inherited a limit meant for a different use case.

I ran into this on a self-hosted instance with 16 active siteIds where only 10 were reachable from the dropdown. Sites outside the top 10 by hit count can still be opened by editing ?site= in the URL, but the selector then renders blank, since the value isn't among its items.

Changes by Package

@counterscale/cli

No changes.

@counterscale/server

• app/routes/dashboard.tsx: pass an explicit MAX_SITES = 1000 for the dropdown query. getSitesOrderedByHits' own default of 10 is left alone, so the redirect call site is unaffected.
• app/routes/__tests__/dashboard.test.tsx: regression test asserting the dropdown query is not capped at the default. It fails on main with expected 10 to be greater than 10.

@counterscale/tracker

No changes.

Other Changes

None.

Additional Notes

Verified locally: pnpm test (174 passed), pnpm typecheck, pnpm build, plus prettier and eslint clean on the touched files.

1000 is intended as "effectively unbounded for any realistic deployment" while staying well under Analytics Engine's own row cap. Happy to use a different number, or to drop the LIMIT from that query entirely if you would rather the dropdown be truly unbounded.