Reviewing a docs PR currently means running the contributor's markdown
locally with archbee dev, which executes untrusted content in the
reviewer's browser (#340). This adds an automated preview instead:

* tools/preview/snapshot.mjs renders every page of the archbee dev
  server in headless Chrome and saves a static, script-free copy.
  There is no static-export command in the Archbee CLI and fetching
  pages plainly returns an empty SPA shell, so a real browser does the
  rendering. All script tags and inline handlers are stripped and all
  root-absolute URLs are rewritten relative, so the snapshot can be
  served from any subpath and carries no executable JS from the PR.

* docs-preview-build.yml (pull_request) builds that snapshot with a
  read-only token and uploads it as an artifact. It never sees secrets,
  which is what makes it safe to run on fork PRs.

* docs-preview-deploy.yml (workflow_run) runs trusted code only,
  validates the artifact's PR number against the API, publishes the
  snapshot to gh-pages under pr/<n>/, and maintains a sticky PR comment
  with the preview link.

* docs-preview-cleanup.yml (pull_request_target, closed) deletes
  pr/<n>/ from gh-pages. It never checks out PR code, which is the one
  condition under which pull_request_target is safe.

Maintainers need to enable Pages once: deploy from branch, gh-pages,
root. The gh-pages branch is created on first deploy.