Improve worker version reporting, navigation, and contributor tooling

[aerickson]

Summary

Improve the worker-version report's navigation and make its capacity, image, and probe results easier to interpret. Replace worker totals that included stopped records with configured capacity ranges, expose report provenance, and add tools for refreshing and previewing reports locally.

User-visible changes

• Add a responsive, collapsible table of contents, accessible heading permalinks, and links from worker pools to Worker Manager.
• Show configured worker/capacity ranges and slots per worker, with explicit handling of unavailable values. Clarify that summaries count worker pools, not individual workers or tasks.
• Improve sorting for versions, capacity ranges, and numeric columns; shorten Azure image labels while retaining full references in hover text.
• Clarify unknown-implementation versus unclaimed-probe results, graph labels, and tooltips.
• Show probe/collection timestamps, the probe task group, report-generation time, source revision, and history coverage when available. Warn when the probe is more than ten days old.
• Link to the existing migration timeline from History and the Docker Worker introduction. Rendered links stay on the current site; the Markdown report retains a public URL.

Reporting and contributor tooling

• Collect provider, image, configured capacity, slots-per-worker, and derived worker ranges from Worker Manager. Distinguish standalone pools from lookup failures.
• Write new worker snapshots as an object containing timestamps, the task-group ID, and workers.
• Add task-group status polling and offline Markdown rendering to audit-worker-versions.
• Add a local refresh script with resumable probe collection and ~/.tc_token support, plus local preview tooling.
• Add optional personal Quick preview helpers under scripts/quick/. They package the checkout's report and snapshot, use explicit personal/staging site names, and require confirmation unless --confirm is supplied. Quick SDK/styles are injected only into the deployment package.
• Add read-only CI for pull requests and pushes to master, covering Go, Python, JavaScript, and Firefox layout tests. Browser tests render the report in memory from the saved snapshot rather than requiring generated artifacts in the PR.

Compatibility and scope

New collections store workers under .workers instead of at the JSON document root. The repository's history and offline rendering tools accept both formats; external consumers expecting a bare array will need to be updated. Legacy snapshots lack the new probe/configuration metadata, so those fields appear only when available; legacy worker totals are intentionally not presented as configured capacity.

This PR leaves the committed worker snapshots, generated report, and history data unchanged. Report-template changes become visible when the Markdown report is regenerated. Existing NAS collection and branch-based Pages publishing remain in place. Scheduled probe/report automation and optional Actions-based Pages publishing are reserved for a separate follow-up.

Validation

• go test ./...
• python3 -m unittest test_fetch_and_generate.py — 4 passed
• npm test --prefix docs — 16 passed
• npm run test:browser in docs/ — 5 Firefox layout tests passed
• actionlint .github/workflows/ci.yml
• git diff --check

Quick preview deployment was verified with a live deployment of the latest Quick changes.

[lotas]

would you mind pinning those versions a bit?
zizmor suggests we do:

INFO zizmor: 🌈 zizmor v1.29.0
 WARN audit: zizmor: zizmor is running in offline mode by default; some audits and auto-fixes will not be available. see https://docs.zizmor.sh/usage/#operating-modes for details
 INFO audit: zizmor: 🌈 completed ci.yml
error[unpinned-uses]: unpinned action reference
  --> ci.yml:21:15
   |
21 |       - uses: actions/checkout@v6
   |               ^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ci.yml:24:15
   |
24 |       - uses: actions/setup-go@v6
   |               ^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ci.yml:27:15
   |
27 |       - uses: actions/setup-python@v6
   |               ^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ci.yml:30:15
   |
30 |       - uses: actions/setup-node@v6
   |               ^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ci.yml:46:15
   |
46 |       - uses: actions/checkout@v6
   |               ^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ci.yml:49:15
   |
49 |       - uses: actions/setup-go@v6
   |               ^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ci.yml:52:15
   |
52 |       - uses: actions/setup-python@v6
   |               ^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ci.yml:55:15
   |
55 |       - uses: actions/setup-node@v6
   |               ^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

error[unpinned-uses]: unpinned action reference
  --> ci.yml:71:15
   |
71 |         uses: actions/upload-artifact@v4
   |               ^^^^^^^^^^^^^^^^^^^^^^^^^^ action is not pinned to a hash (required by blanket policy)
   |
   = note: audit confidence → High

[aerickson]

Done.

[lotas]

Thank you