Move component assets to a new bucket, with versioned paths

[t4k]

These components are published to media.library.caltech.edu because that
bucket already existed for other purposes, not because it was set up for them.
They ride along in a shared space, under a prefix, alongside unrelated content.

A bucket for embeddable assets, separate from whatever else that one holds, is
worth doing on its own. It also happens to be the moment several other problems
become cheap to fix, all of which get more expensive the longer they wait.

1. Consumers cannot pin a version

https://media.library.caltech.edu/cl-webcomponents/footer-global.js

No version in the path. A site embedding that gets whatever was published
last, with no way to ask for a specific release and no warning when it
changes. The only way to discover what you are running is to read the
version export out of the bundle — and that export was wrong for thirteen
months, reporting 0.0.12 while the project was at 0.0.16, until #48.

This is the one that is genuinely hard to retrofit. Adding versioned paths to
the existing layout means either breaking every URL already in use or serving
two schemes indefinitely. Doing it as part of a move costs nothing extra.

A scheme worth copying is the one caltechlibrary/workflows uses for its
actions: an exact version that never changes, plus a moving major tag for
callers who want fixes automatically.

/cl-web-components/0.0.17/footer-global.js   pinned, immutable
/cl-web-components/v0/footer-global.js       moves with each release

Consumers choose which contract they want.

Which surfaces a problem with the version number itself. codemeta.json
says 0.0.16. Under SemVer a 0.x.y version means explicitly no stability
promise — anything may change at any time. These components are in production
on Caltech Library sites, so that is not what we mean.

It matters here rather than being pedantry: a moving v0 tag has nothing to
move within. The whole point of a major tag is "keep giving me fixes that
will not break me," and 0.x makes no such offer. There is no compatible line
to track.

The reason not to have released 1.0.0 before was that the delivery mechanism
could not keep the promise — with unversioned paths, consumers cannot pin, so
declaring stability is meaningless. This proposal removes that objection.
Versioned paths and a 1.0.0 release are the same conversation.

2. The bucket is named after its public hostname

That makes AWS_BUCKET_NAME a secret that protects nothing — the hostname is
public and appears in dozens of files here — while breaking output that
legitimately contains the same string. GitHub masks a secret's value
wherever it appears, so public-base-url, which is a plain literal in the
workflow and not a secret at all, renders in the publish job summary as:

BASE_URL: https://***/cl-webcomponents/

Every link in that summary is unclickable. A bucket name that is not the
hostname makes the secret meaningful and the summary useful, at the same time.

3. The prefix is missing a dash

cl-webcomponents, where every other spelling of the project name has one:

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

Correcting it on the current bucket means migrating objects or running two
paths in parallel. On a new bucket it is simply the name we choose.

4. Two hosts serve the same components

software.library.caltech.edu is the GitHub Pages custom domain, rebuilt on
every push. media.library.caltech.edu is S3, updated on release. They served
different versions of the same files for over a year, and the documentation is
split between them:

Referenced in this repo	Count
media.library.caltech.edu/cl-webcomponents/	8
software.library.caltech.edu/CL-web-components/	4
software.library.caltech.edu/CL-web-compents/ — typo, 404	1

That last one is in INSTALL.md, inside the copy-paste import statement, so
anyone following the install instructions gets a 404.

A move is the natural moment to decide which host is canonical for embedding
and make every reference agree.

5. Related: rename the repository to cl-web-components

The project is spelled at least three ways today — CL-web-components as the
repository, cl-webcomponents as the bucket prefix, cl-web-components in
prose and in the npm-style name. If the prefix is being fixed anyway, the
repository name is the other half of the same inconsistency, and lowercase
matches every other spelling.

Separable from the bucket work, but it belongs in the same conversation because
it changes URLs at the same time.

What it affects:

• The documentation site URL changes, from
  software.library.caltech.edu/CL-web-components/ to
  .../cl-web-components/. This is the real cost — every documented link and
  every bookmark. GitHub redirects the repository URL, but the Pages path
  follows the repository name.
• build-pandoc's site-base defaults to /<repo>/, so the built pages
  follow automatically. No workflow change needed.
• Page titles change, since project defaults to the repository name.
• codemeta.json and CITATION.cff carry the repository URL.
• Existing clones keep working — GitHub redirects the old name — but anyone
  with a remote pointing at the old URL should update it.

What has to change together

• 13 component URLs in this repository — docs, demo pages, INSTALL.md
• .github/workflows/publish-to-s3.yml — prefix and public-base-url
• caltechlibrary/workflows, pandoc/page.tmpl line 16 — loads
  footer-global.js from the CDN, so this reaches every Caltech Library
  documentation site using the shared build, not just this project
• the Caltech Library logo, served from media.library.caltech.edu/assets/ by
  the same template — same bucket, and possibly a different owner
• any consumer outside these two repositories, which we have not surveyed

Decisions needed

• Hostname. assets.library.caltech.edu has been suggested.
• Bucket name, deliberately not the hostname.
• Path scheme. Exact versions only, moving major only, or both.
• Whether the current path keeps serving, and for how long. Nothing forces
  a cutover if both can run during a transition.
• Who owns the assets/ prefix the logo is served from.
• Whether software.library.caltech.edu should keep serving components at
  all, or go back to being only the documentation site.
• Whether to release 1.0.0 alongside versioned paths, and whether to
  rename the repository. Both are separable; both change URLs, so doing them
  apart means disrupting links twice.

Not in scope

The documentation site's own hostname. This is about where embeddable assets
live, not where docs are published.