feat: split data update from site build; publish via Cloudflare Pages

The updater fetched GitHub metadata and rendered the dashboard payload in
a single step, so anything that published the site needed a GITHUB_TOKEN.
Cloudflare Pages builds from a Git webhook and has no business holding
one.

Split the tool into three modes. The default update step still fetches
GitHub and now records every API-sourced field in data/metadata.json,
which is committed alongside README.md and data/history.jsonl. The new
-build mode joins that snapshot with data/agents.yml and
data/history.jsonl to render dist/ with no network access and no token;
-check is unchanged.

Supporting changes:

- computeDeltaAt anchors the delta windows to when the data was fetched
  rather than the wall clock, so a redeploy days later reproduces the
  same Δ7d instead of sliding the window past its slack allowance.
- writeSiteData takes updatedAt explicitly for the same reason: the
  timestamp labels data freshness, not build time.
- sortStats is extracted from fetchStats so the build step re-ranks
  identically from committed metadata.
- An agents.yml entry with no metadata yet is omitted with a warning
  instead of failing the build, which would otherwise block every deploy
  between merging a new entry and the next nightly run.
- update.yml drops the GitHub Pages deploy steps and commits
  data/metadata.json; ci.yml runs `go run . -build` so a build that would
  break on deploy breaks in CI first.
- site/_headers stops the edge serving a stale data.json after a refresh.
- docs/DEPLOY.md covers the Cloudflare setup, including the one-time
  bootstrap of data/metadata.json that the build depends on.

Also carries the in-progress curation work already in the tree: the
module rename to awesome-ai-dev-tools, retagged entries, and removal of
the archived Roo-Code, void, continue and suna entries.

docs/CONTRIBUTING.md

@@ -41,8 +41,11 @@ The dividing line is **tools you use vs. building blocks you import**. Out of sc
 libraries and SDKs, agent frameworks meant to be built on, model weights, prompt or
 skill collections, and dashboards that only observe a tool without being one.
 
-A tool also has to be *about* software development. General-purpose assistants and
-chat UIs do not qualify just because a developer could use them.
+A tool also has to be *about* software development. General-purpose assistants,
+chat UIs, and multi-agent "digital workforce" apps — the ones whose specialists write
+reports, decks, and marketing copy — do not qualify just because a developer could use
+them, or because one of their agents happens to touch code. Judge the tool by what it is
+built to do, not by the widest thing it can be pointed at.
 
 ### The star floor is hard
 
@@ -63,7 +66,7 @@ describe a tool that ships as a CLI, an editor plugin and a desktop app at the
 same time — which most of them now do. An entry carries several tags across
 five facets. `data/agents.yml` is the source of truth; the vocabulary itself
 lives in `tagVocabulary` (`validate.go`) and reaches the dashboard through
-`site/data.json`, so it is defined exactly once.
+the generated `dist/data.json`, so it is defined exactly once.
 
 **Surface** — where you run it. At least one required.
 
@@ -121,6 +124,9 @@ say nothing about choosing the tool. GitHub topics are a drafting aid only —
 **Deprecation:** To remove an agent, delete its entry from `data/agents.yml`. The next run drops it from the README; its history stays in `data/history.jsonl`, so re-adding the entry later restores its star chart.
 
 **Staleness:** An entry with no push in **6 months** is dropped. Past **3 months** the updater prints a `::warning::` naming the repo and its days idle, so the daily run surfaces candidates without anyone auditing the list by hand. Removal stays a human decision: a repo can go quiet between releases, and a historically significant one (`gpt-engineer`) is kept with a `notes` marker instead.
+A repo the maintainers have **archived or declared deprecated** is different: it will never
+be pushed again, so it is removed without waiting out the 6 months unless it earns the same
+historical-significance exception.
 
 ## PR Review
 
@@ -128,4 +134,5 @@ say nothing about choosing the tool. GitHub topics are a drafting aid only —
 - The daily GitHub Actions workflow (runs at 00:00 UTC) picks up merged PRs automatically
 - No manual review required; the updater regenerates the README after your PR merges
 
-For local testing before opening a PR, see [LOCAL_DEV.md](./LOCAL_DEV.md).
+For local testing before opening a PR, see [LOCAL_DEV.md](./LOCAL_DEV.md). A tag
+or note change needs only `go run . -build` — no GitHub token.