fix: point the Netlify project at the redirects too

The PR that switched the GitHub Pages deploy to redirects missed that this
repository is built by a Netlify project as well. That project has no config
in the repository, so its build command lives in Netlify's web UI, where a
change to .github/workflows/deploy.yml cannot reach it — it would have gone on
building and publishing the old mkdocs site regardless.

Two consequences, one of them visible right now: the deploy preview on this
pull request is the old site, which makes the redirects look broken to anyone
who clicks it, and any production deployment of that project is a third live
copy of the old site that neither the Pages redirects nor archiving would
touch.

Adds a netlify.toml so the build is defined in version control. It runs the
same redirect builder, and declares real 301s — Netlify can serve those, unlike
Pages — with the /projects/ rule ahead of the catch-all, since Netlify takes
the first match and that is the one page that did not survive as its own URL.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U9zFxq8V4qxG4aMzJhGBFn

Author: claude

README.md

@@ -34,6 +34,10 @@ verifies the map still covers every URL the old site served. GitHub Pages has
 no server-side redirect table, so each stub is a `rel=canonical` plus a
 `<meta refresh>` — the canonical is what moves search ranking to the new URL.
 
+Two hosts serve this repository, so both are covered: GitHub Pages gets the
+stubs, and `netlify.toml` gives the Netlify project real 301s and stops it
+building the old site from a command configured in its web UI.
+
 ## Why the redirects come before the archive
 
 Archiving a repository makes it read-only and stops its Actions from running,

netlify.toml

@@ -0,0 +1,33 @@
+# This repository is also wired to a Netlify project, which until now built the
+# mkdocs site from a command configured in Netlify's web UI. That command is
+# invisible from here and outlives any change to the GitHub Actions workflow,
+# so without this file Netlify would keep publishing the old site after the
+# GitHub Pages deploy had been switched to redirects — and the deploy preview
+# on a pull request would show the old site too, which makes the redirects look
+# broken when they are not.
+#
+# Settings here override the UI, so the build is defined in version control.
+
+[build]
+  command = "python scripts/build_redirects.py"
+  publish = "site"
+
+# Netlify, unlike GitHub Pages, can serve a real 301. These take precedence
+# over the stub files the build writes, which stay as the fallback for hosts
+# without a redirect table.
+#
+# Order matters: Netlify takes the first rule that matches, so the one page
+# that did not survive as its own URL has to come before the catch-all.
+[[redirects]]
+  from = "/projects/*"
+  to = "https://commit-check.com/"
+  status = 301
+  force = true
+
+# Everything else kept its path on the new site, so the tail is carried across
+# unchanged. This also covers URLs the stub list does not enumerate.
+[[redirects]]
+  from = "/*"
+  to = "https://commit-check.com/:splat"
+  status = 301
+  force = true