Restructure: deploy a site/ directory instead of a hand-maintained allowlist, and cap source images at 4K

Follow-up to #99 / #100, which fixed one symptom: llms.txt was linted and
link-checked on every PR but never deployed, because static.yml assembles
_site/ from a hand-written list of filenames and nobody remembered to extend it.

That list is the actual defect. It is easy to add a file next to and forget.

Part 1 — move deployable content into site/

Why not a denylist at the repo root

Worth stating, because it is the obvious idea and it is the one option that
cannot work here. The root is shared: main's Astro rebuild builds dist/,
.astro/ and node_modules/ in this same working directory, and .venv/,
.claude/ worktrees, megalinter-reports/ and lighthouse-reports/ all land at
root too. "Copy everything except X" from root means the next ignored directory
someone adds leaks into production. The allowlist exists for that reason and the
reason is sound.

Why site/ fixes it properly

It turns the boundary from a list of filenames into a directory:

cp -r site/. _site/

Exhaustive by construction. Tooling cannot leak because it lives outside site/.
A new page is deployed and link-checked with no list to remember, once
links.yml globs site/**/*.html.

_site/ still exists as a staging copy — scripts/optimize-images.mjs rewrites
images in place and must not touch the repo's masters. The goal is not to remove
the staging step, only to make the copy exhaustive rather than enumerated.

Naming

site/, not src/. There is no compile step, and main uses Astro's
src//public/ conventions in this same working directory — worth not
overloading the word.

What has to move out of the deployable tree

Two image directories are in the repo deliberately and deliberately never served;
static.yml currently rm -rfs them from _site/ after copying. If images/
moves wholesale into site/ they come along and the denylist is back, just
smaller. Move them to originals/ at root instead:

• images/will/JPEGs/ — 3.6 MB of masters; only JPEGs_FBK/ is referenced (one headshot, 2026_Headshot_1x1.jpg)
• images/gallery/photographer/product/ — 13 MB, unreferenced by any page

Both confirmed unreferenced by grep across all HTML, CSS, JS, XML and txt. After
this, "in the repo but not served" stops being a rule inside a workflow and
becomes a fact about where the file lives.

assets/sass/ is source, not served, so it moves out too — with npm run css
writing to site/assets/css/main.css.

Not breaking the image links

The thing to get right. Pages and images/ move together, so every relative
path in the HTML (images/foo.jpg) is unchanged — site/index.html referencing
images/foo.jpg resolves to site/images/foo.jpg locally, and to /images/foo.jpg
once site/ is copied to the artifact root. Local preview and deploy both keep
working without editing a single src attribute.

Only the two unreferenced directories above change location, which is exactly why
it matters that they are unreferenced.

Config to update

Mechanical, but it is the bulk of the work:

• .github/workflows/static.yml — the copy step
• .github/workflows/links.yml — lychee globs, both passes
• .mega-linter.yml — FILTER_REGEX_EXCLUDE
• .stylelintignore
• .pre-commit-config.yaml — the standard excludes and build-css files: regex
• package.json — the css and css:check scripts

LICENSE.txt, CLAUDE.md, package.json and the dotfiles stay at root.

Part 2 — cap source images at 4K

190.4 MB of tracked images; .git is 148 MB. 21 MP masters are not worth
carrying when the largest realistic viewport is 4K, and the deploy-time optimizer
caps at 2000px for gallery fulls anyway — so the committed pixels above that are
never served to anyone.

25 files have a long edge over 3840px, totalling 94.9 MB. Gallery fulls are
5184x3456.

One decision to make: 2160p is a height, and a cap has to handle both
orientations. Suggest capping the long edge at 3840 regardless of orientation
— simple, and portrait images end up 2560x3840 which is still more than a 4K
display can show. Capping the short edge instead would leave panoramas enormous.

Note this is mostly about repo weight, not site performance — optimize-images.mjs
already handles what gets served.

Sequencing

1. #100 — llms.txt, landed separately
2. #101 first. 71.5 MB of the 190 MB is trailing garbage after the JPEG EOI marker, recoverable losslessly. Do that before any resize work so the resize is applied to sane files and the diff is readable.
3. originals/ split + site/ move — two commits, one PR, so a reviewer can see the file list is otherwise identical
4. 4K cap as its own PR, since it is the only part involving quality judgement

Acceptance criteria

• _site/ built the new way is byte-identical to the old way, apart from llms.txt
• Deploy step contains no per-file list
• Every image renders, checked on every page, both locally and on a deploy preview
• Nothing outside site/ reaches the artifact — assert the deployed file set equals git ls-files site/
• No committed image exceeds 3840px on its long edge
• links.yml picks up a newly added page with no workflow edit

Related: #31 (v2 image pipeline on main — same underlying problem, different
branch and a different fix; this issue is v1 on master, and the two are
complementary rather than duplicates).

Start with #101, then inspect .github/workflows/static.yml and links.yml, .mega-linter.yml, .stylelintignore, .pre-commit-config.yaml, package.json, and scripts/optimize-images.mjs. Run the existing CSS and validation commands to establish the current artifact, then verify the new site/ layout, image locations, link globs, and 3840px long-edge limit against the listed acceptance criteria.