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>

extension/README.md

@@ -38,27 +38,42 @@ npm run build                # unsigned XPI in web-ext-artifacts/
 - [ ] Subscriptions list: popup → "Sources" tab → list renders
 - [ ] Check now: click play icon on source row → no error toast
 
-## Versioning — don't hand-edit the patch number
+## Versioning — the committed number decides nothing
 
 The shipped version is **derived**, not committed. `scripts/packaging.sh
-version` returns `MAJOR.MINOR` from `manifest.json` plus a patch component
-that is the commit *time* of the newest change to a packaged extension file,
-in minutes since 2020-01-01. `build.yml` computes it and stamps it into both
+version` returns `YYYY.M.D.HHMM` in UTC: the commit *time* of the newest change
+to a packaged extension file. `build.yml` computes it and stamps it into both
 `manifest.json` and `package.json` at build time. The stamp is never
 committed — the commit carrying it would itself be a change to the extension,
 which would move the version again.
 
 So:
 
-- **Editing the patch number does nothing.** It is overwritten before web-ext
-  ever reads it. There is no bump to make, and none to forget.
-- **MAJOR.MINOR is still yours.** It carries the deliberate meaning, it is read
-  from `manifest.json` alone, and CI fails the `extension-version` lane if the
-  two files disagree on it.
+- **Editing the version does nothing.** All of it is overwritten before web-ext
+  ever reads it. There is no bump to make, and none to forget. There is no
+  hand-set part left either: MAJOR.MINOR went away with milestone 318 step 8.
 - `npm run build` locally produces an XPI labelled with the *committed*
   version, since nothing stamped it. Fine for loading into a test profile; not
   what ships.
 
+**Why the extension is the one artifact that does not zero-pad.** Every other
+FC artifact emits rule 148's `YYYY.MM.DD.HHMM`. AMO will not take it: Mozilla's
+grammar for addons.mozilla.org is
+
+```
+^(0|[1-9][0-9]{0,8})([.](0|[1-9][0-9]{0,8})){0,3}$
+```
+
+— each segment is the single digit `0` or starts 1-9, so `08` and `0201` are
+rejected, and at most four segments are allowed. The extension therefore emits
+**the same numbers unpadded**: `2026.8.29.201` where the rest of the family
+says `2026.08.29.0201`. Rule 148 already defines comparison as numeric per
+segment, under which the two are equal, so nothing is reordered by the choice
+and left-padding each segment recovers the family string exactly. `ci.yml`'s
+`extension-version` lane checks the derived string against that regex on every
+push — the cheap place to find out, because AMO 409s on re-signing and a
+rejected version is burned for good.
+
 Why commit time and not a commit count: a count is per-branch, so `dev` and
 `main` count different histories of the same code and their versions end up
 ordered by which branch accumulated more commits rather than by which is newer.