Evaluate moving to a GitHub Actions Jekyll deploy (enabler for V2.0)

[jonfroehlich]

Summary

Several roadmap items toward the "Version 2.0" textbook release are blocked by the same constraint: the site is published with the default GitHub Pages Jekyll build, which only runs whitelisted plugins and does no custom build steps. Moving to a GitHub Actions–based Jekyll deploy (build with Actions, publish _site to Pages) removes that constraint and unlocks multiple features at once.

Why

The default GitHub Pages build cannot:

• Run custom Jekyll plugins (blocks the figure-reference feature).
• Fetch/checkout the source-code repo and inline code at build time (blocks build-time code embedding).
• Run lint/test gates on content (blocks a code-block consistency CI check).

A GitHub Actions workflow can do all of the above, and is the current GitHub-recommended way to deploy Jekyll to Pages.

What this unblocks

• Build-time source-code inlining (single source of truth, but static/accessible/indexable) — see the code-embedding strategy issue.
• LaTeX-style clickable, auto-numbered figure references (could use a real plugin instead of pure client-side JS) — see the figure-reference issue.
• CI lint/test gate for content (code-block consistency, markdownlint, link checking, Arduino URL checks) — see the code-block standardization issue.

Tasks

• Spike a GitHub Actions workflow that builds the site with actions/jekyll-build-pages (or a custom Ruby + bundle exec jekyll build) and deploys via actions/deploy-pages.
• Confirm build times are acceptable vs. the current default build (builds are already 20s+).
• Verify remote_theme, baseurl, and all current behavior still work.
• Document the new deploy pipeline in website-dev.md.
• Once in place, revisit the dependent issues.

This is a meta/enabler issue; the dependent issues link back here.