chore: migrate installs-cache from docs to cycles-docs after repo rename

[amavashev]

What

The repo `runcycles/docs` was renamed to `runcycles/cycles-docs`. `.vitepress/theme/installs-cache.json` still has the old name in both `clonesByRepo` and `releasesByRepo`. Renaming those keys in place avoids a double-count on the next scheduled run.

The bug (without this fix)

`fetchGithubClones` (in `installs.data.ts`) and `updateClones` (in `scripts/update-github-counts.mjs`) both:

1. Call `listOrgRepos()`, which returns the live GitHub list — now contains `cycles-docs`, not `docs`.
2. For `cycles-docs`, the cache lookup falls back to default `{ count: 0, lastSeenDay: '' }`.
3. All 14 days in the `/traffic/clones` API window pass the `day > cached.lastSeenDay` check, so a fresh `cycles-docs` entry gets seeded with 14 days of clones in one bulk addition.
4. The old `docs` key in `clonesByRepo` is preserved by `{ ...cachedByRepo }` (installs.data.ts:359; update-github-counts.mjs:108). Nothing iterates removed keys to migrate or prune them. It becomes a zombie at count=16064.
5. `clones = Object.values(updated).reduce((a, b) => a + b.count, 0)` sums both the zombie `docs` (16064) and the freshly seeded `cycles-docs` (~14 days) — double-counting the overlap.

The displayed total (`total: 13319`) was not affected because clones are explicitly excluded from the displayed total (installs.data.ts:511). Only the homepage clones counter (`cache.clones`) was at risk.

The fix

Rename the cache keys directly: `docs` → `cycles-docs` in both `clonesByRepo` and `releasesByRepo`. Count and `lastSeenDay` cursor carry over unchanged, so:

• The aggregate `clones` field stays at 70541 (sum verifies).
• The next loader run reads `cycles-docs` from a populated entry with `lastSeenDay: '2026-05-14'` — only days strictly after that get added incrementally. No bulk re-seed.
• The zombie `docs` key is gone.

Releases migration is cleanup-only (the cached value was 0, so no double-count, but the zombie key is cleared for tidiness).

Follow-up worth considering

The scripts have no rename-detection mechanism. If another repo is renamed in the future, the same bug recurs. Two paths:

1. Recommended: Add a `REPO_RENAMES` map in `update-github-counts.mjs` that migrates cached entries from old to new names at the start of each run. Manual maintenance, but the safest approach (one line per rename).
2. Riskier: Auto-prune cached keys not in the current `listRepos()` result. A temporary API failure or a repo briefly archived could wipe legitimate cached state.

Worth filing as a follow-up; for this PR, the one-off data migration is sufficient.

Test plan

• `npm run build` succeeds with the migrated cache
• After build, verify `clones` field in installs-cache.json still ≥ 70541 (the HWM guard at installs.data.ts:139–168 should preserve it)
• Verify `clonesByRepo['cycles-docs']` is present with count=16064; `clonesByRepo['docs']` is absent
• Verify homepage clones counter is unchanged
• Confirm next scheduled run of `update-github-counts.mjs` adds only days > 2026-05-14 to `cycles-docs` (no 14-day bulk seed)