ci(extension): shadow the derived version + verify real XPI contents

Milestone #271 steps 2 and 3. Neither changes what gets published.

STEP 2 -- shadow mode.

build.yml's sign-extension and ci.yml's extension-version guard now log the
version that WOULD be derived from git history alongside the hand-maintained
one. Nothing reads the derived value, and neither site can fail because of it.

This exists because `web-ext sign` is one-shot per version: AMO 409s on a
repeat, so a wrong formula burns a real version number that cannot be
reclaimed. Comparing the two across real builds is the only way to validate it
at zero cost. sign-extension runs on main only, so main pushes are the sole
source of truth for whether the derived number moves exactly when the shipped
extension changes -- the dev-side log is a convenience, not the evidence.

sign-extension now checks out with fetch-depth: 0. The derived version is a
commit count and a depth-1 clone cannot produce one.

STEP 3 -- XPI content verification.

Every other packaging assertion checks our declaration against itself. This is
the first that asks web-ext what it ACTUALLY wrote into the archive.

That assumption was both unverified and fragile: `test/**` only survives to
web-ext because callers `set -f` before substituting it, so losing that
quoting would silently start shipping dev files with no other signal. The step
builds the XPI and asserts test/, scripts/, vitest.config.js, package.json,
package-lock.json, README.md and node_modules are absent -- and, because an
over-matching exclusion would break the extension at runtime rather than at
build time, that manifest.json, all four lib/*.js and every UI directory are
present.

unzip is installed only when missing; node:24-bookworm-slim may not carry it.

Refs #2399, #2400

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.forgejo/workflows/build.yml

@@ -40,6 +40,11 @@ jobs:
       image: git.fabledsword.com/bvandeusen/ci-python:3.14
     steps:
       - uses: actions/checkout@v4
+        with:
+          # Full history: the shadow-mode step below derives a version from a
+          # commit count, which a depth-1 clone cannot produce. Harmless for
+          # everything else in this job.
+          fetch-depth: 0
 
       - name: Resolve extension version
         id: extver
@@ -48,6 +53,25 @@ jobs:
           echo "version=$VERSION" >> "$GITHUB_OUTPUT"
           echo "Resolved extension version: $VERSION"
 
+      # --- shadow mode (milestone #271, step 2) ---------------------------
+      # Informational ONLY — nothing downstream reads this, and it must never
+      # fail the build. This is THE place the derived formula gets validated:
+      # `sign-extension` only runs on main, so main pushes are the sole source
+      # of truth for whether the derived version moves exactly when the shipped
+      # extension changes. Compare these lines across several main builds
+      # before step 4 lets the derived value control publishing.
+      - name: Shadow — derived version (informational)
+        run: |
+          set -u
+          DERIVED=$(sh extension/scripts/packaging.sh version 2>&1 || echo "UNAVAILABLE")
+          MANUAL=${{ steps.extver.outputs.version }}
+          echo "shadow: manual=$MANUAL derived=$DERIVED sha=$GITHUB_SHA"
+          if [ "$MANUAL" = "$DERIVED" ]; then
+            echo "shadow: manual and derived agree"
+          else
+            echo "shadow: DIVERGENT — expected until step 4 cuts over; derived is authoritative-to-be"
+          fi
+
       - name: Check Forgejo release-asset cache
         id: cache
         env: