Publish components to S3 from Actions

[t4k]

Replaces publish_to_s3.bash and invalidate_cdn.bash.

What was wrong

The old script needed an uncommitted media.env to exist on someone’s machine,
so whether the CDN was current depended on who had run it lately. Nobody had
since July 2025:

	Version
media.library.caltech.edu/cl-webcomponents/ (CDN copy)	0.0.12, hash 9729d57
software.library.caltech.edu/CL-web-components/ (Pages, rebuilt every push)	0.0.16

invalidate_cdn.bash also invalidated /* — every other project on that
distribution, not just this one.

What replaces it

.github/workflows/publish-to-s3.yml, calling
caltechlibrary/workflows/.github/actions/publish-to-s3@v1. Authentication is
OIDC, so no AWS keys exist in this repository or on anyone’s machine.

Runs when a release is published, and manually from the Actions tab with
dry_run on by default — that reports exactly what would be uploaded and
invalidated without touching anything.

Two fixes come from the shared action rather than from here: invalidation is
scoped to this project’s prefix, and content types are set explicitly rather
than guessed.

sources: dist

Just dist now. Component stylesheets build into it alongside the bundles as of
#50, and the docs theme’s CSS is no longer this project’s to publish — that
moved to caltechlibrary/workflows in its v1.2.0.

A side effect worth noting: textarea-agent-list.css gets published for the
first time. css-href is a documented consumer feature and its default
stylesheet has been returning 404 on both hosts.

The prefix stays cl-webcomponents

No dash between "web" and "components". It reads like a typo, but it is where
the objects are:

200  media.library.caltech.edu/cl-webcomponents/footer-global.js
404  media.library.caltech.edu/cl-web-components/footer-global.js

Changing it would publish to a new empty path rather than update what consumers
load. Correcting the spelling means migrating, which belongs with the eventual
move to a versioned asset domain.

The eleven root bundles go too

They existed to be uploaded by publish_to_s3.bash, and nothing else read
them. Verified before deleting:

• docs.yml includes dist/*.js, dist/*.css, mod.js, LICENSE, src —
  not the repository root
• the demo pages reference bare filenames like src="textarea-csv.js", which
  resolve against the published site root, where dist/*.js lands — not
  against the repository
• Makefile:81 does cd dist && zip …, so make dist zips from dist/
• deno.json only references src/*.js and dist/

Their last consumer is deleted in this change, so they follow it.

mod.js stays. It is authored source that imports from src/, and the site
includes it deliberately.

Documentation

docs/DEPLOYMENT.md walked through the manual path step by step and is
rewritten to match: merge, the docs site rebuilds itself, the CDN updates on
release or on a manual dispatch.

Its release section still describes make dist and release.bash. Those stay
until the release workflow lands, so that section is deliberately untouched.

Before merging

Worth one manual dispatch with dry_run checked, to confirm the OIDC role and
the file list before anything real is written.