fix: let the Pages job enable Pages itself

configure-pages fails with a 404 when Pages has never been switched on for
the repository. It can enable it given the pages: write permission the job
already holds, which beats requiring a trip through settings before CI can
go green.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

.github/workflows/ci.yml

@@ -131,6 +131,12 @@ jobs:
           name: site
           path: public
       - uses: actions/configure-pages@v5
+        with:
+          # Turn Pages on rather than requiring someone to click through
+          # repository settings first. Needs the pages: write permission above.
+          # If this still fails, Pages is unavailable for the repository —
+          # private repos on the free plan cannot use it; delete this job.
+          enablement: true
       - uses: actions/upload-pages-artifact@v3
         with:
           path: public

README.md

@@ -153,7 +153,8 @@ so iteration never re-fetches. Every event links back to its source.
 
 Both `.github/workflows/ci.yml` and `.gitlab-ci.yml` run the same gates on every push — typecheck,
 tests, and a feed sanity check — then build and publish a container image from the default branch.
-GitHub Actions additionally deploys to Pages.
+GitHub Actions additionally deploys to Pages, enabling it on first run. Pages is unavailable for
+private repositories on the free plan — delete the `pages` job if that applies.
 
 The feed job fails if the event count collapses. A source that quietly stops yielding events is the
 failure mode a parser-only pipeline is most prone to, and nothing else would surface it. Everything