feat(extension): derive the version as unpadded CalVer (milestone 318 step 8)

`1.0.<minutes since 2020>` -> `YYYY.M.D.HHMM` UTC, from the commit time of
the newest change to a packaged extension file. Same clock and same commit as
before; readable instead of opaque, and the same value the rest of the family
derives.

The hold on this step was two questions about AMO, and Mozilla's own docs
answer both:

    ^(0|[1-9][0-9]{0,8})([.](0|[1-9][0-9]{0,8})){0,3}$

  1. four all-numeric segments -> ACCEPTED ({0,3} more after the first).
  2. leading zeros              -> REJECTED. A segment is the single digit
     `0` or starts 1-9, so `08` and `0201` are refused. MDN says it in prose
     too: "Non-zero numbers must not include a leading zero."

So the documented fallback applies, extension only: the same numbers rendered
without the family's zero-padding. `2026.08.29.0201` and `2026.8.29.201` are
one value in two renderings — rule 148 defines comparison as numeric per
segment, under which they are equal — so nothing already published is
reordered, and left-padding each segment recovers the family string exactly.
HHMM stays one segment because AMO allows at most four.

The transition is safe in the other direction too: 2026 > 1, so every CalVer
outranks every published 1.0.x. build.yml's downgrade guard confirms it.

Also in scope:

* MAJOR.MINOR is gone. `cmd_major_minor`, `cmd_patch` and VERSION_EPOCH go
  with it, the committed version in manifest.json / package.json is now
  wholly inert, and ci.yml's MAJOR.MINOR-agreement check is retired rather
  than left running beside a fact that stopped existing (rule 22).
* ci.yml's `extension-version` lane now asserts Mozilla's regex verbatim
  instead of a loose `^[0-9]+(\.[0-9]+)*$` — which would have passed the
  padded shape. It also asserts YYYY.M.D.HHMM, because AMO would accept a
  regression to `1.0.<minutes>` while that orders below everything signed
  since. Checking here is the point: AMO 409s on re-signing, so a version it
  rejects is burned and cannot be reused.
* `artifacts.sh version extension` delegates to packaging.sh, so the two
  cannot answer differently. The direction matches the existing one —
  artifacts.sh already asks packaging.sh for the extension's path set.

#3156 is what makes this commit safe to make: packaging.sh is in web's path
set, so the web revision moves with the extension version and build-web
rebuilds instead of republishing an image bundling the previous XPI.

Scribe #3138.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

ci-requirements.md

@@ -71,12 +71,25 @@ per `docs/process.md`'s "add deps to the image when used by >1 project".
   published bytes?"*, not *"is this file copied in?"* — which is why the script
   keeps two lists rather than one.
 - **The shipped extension version is derived, not committed.** It is the commit
-  TIME of the newest packaged-extension change (minutes since 2020-01-01, per
-  family rule 149 — never a commit count, which orders by branch rather than by
-  recency). `build.yml`'s `sign-extension` computes it and stamps it into
-  `extension/manifest.json` + `package.json` in the working tree before signing;
-  the stamp is never committed. Treat the version in the repo as a base: only
-  its MAJOR.MINOR is read, and its patch component is inert.
+  TIME of the newest packaged-extension change, rendered `YYYY.M.D.HHMM` UTC
+  (family rules 148/149 — never a commit count, which orders by branch rather
+  than by recency). `build.yml`'s `sign-extension` computes it and stamps it
+  into `extension/manifest.json` + `package.json` in the working tree before
+  signing; the stamp is never committed. The version in the repo is **wholly
+  inert** — since milestone 318 step 8 there is no hand-set MAJOR.MINOR either.
+- **The extension is the one artifact that does not zero-pad, and that is not a
+  drift** (#3138). Mozilla's grammar for AMO is
+  `^(0|[1-9][0-9]{0,8})([.](0|[1-9][0-9]{0,8})){0,3}$` — a segment is the single
+  digit `0` or starts 1-9, and there are at most four. `2026.08.29.0201` is
+  rejected; `2026.8.29.201` is the same value one character narrower per
+  segment, and rule 148 defines comparison as numeric per segment, so nothing is
+  reordered. `ci.yml`'s `extension-version` lane asserts the derived string
+  against that exact regex, plus a `YYYY.M.D.HHMM` shape check that would catch
+  a regression to the pre-318 `1.0.<minutes>` — which AMO would accept and which
+  orders below everything already signed. Checking here is the whole point: AMO
+  409s on re-signing, so a version it rejects is burned and cannot be reused.
+  `scripts/artifacts.sh version extension` **delegates** to `packaging.sh` so
+  the two cannot answer differently.
 - Every job that derives anything checks out with `fetch-depth: 0` — all four
   `build.yml` jobs, `ci.yml`'s `extension-version` and `backend-lint-and-test`
   (for `tests/test_artifact_paths.py` and `test_artifact_identity.py`), and