feat: lock and verify external NGINX artifacts

[joey-huckabee]

Closes the first three Package 2 roadmap items: approve the package channel,
add reviewed architecture locks, and add verified acquisition.

What this adds

• Channel decision. Official NGINX stable, with nginx-2:1.30.4-1.el9.ngx
  selected as the first-release implementation and qualification candidate.
  Reviewed against authoritative NGINX sources on 2026-09-12, including the
  security-advisory index. The selection does not freeze release inputs.
• Architecture locks. artifacts/locks/amd64.json and arm64.json pin the
  selected RPM, its complete 79-package installation closure, 59 source RPMs,
  sizes, SHA-256 values, the actual signer fingerprint, and the builder and
  runtime manifest-list digests. Schema in
  artifacts/artifact-lock.schema.json, reviewed inputs in
  artifacts/lock-inputs.json.
• Lock-update path. fetch-lock-inputs.py (HTTPS-only, approved hosts,
  reviewed SHA-256), resolve-lock.sh (independent inventory, hash,
  fingerprint, signature, NEVRA, architecture, closure, and source-RPM checks),
  and render-lock.py (maps the observed signing key ID to exactly one
  approved fingerprint, fails closed on inconsistent output).
• Acquisition. artifacts.py acquire publishes atomically and refuses to
  replace an existing output directory. verify-rpm-bundle.sh performs
  RPM-level verification before the bundle is exposed to any build.
• Alternate sources. --source-map accepts an external JSON map with
  --token-env and --ca-bundle. URLs with credentials, query strings, or
  fragments are rejected; redirects must stay on the original HTTPS host;
  source URLs and tokens are never printed on error. Maps, credentials, and
  private CA material stay outside this repository and the build context.

Notes for review

• The signer fingerprint for the selected RPMs
  (8540 A6F1 ... B49F 6B46) differs from the older fingerprint in NGINX's
  published install instructions. The locks accept the actual signer
  specifically rather than trusting every certificate in the downloaded
  bundle. See docs/PACKAGE-SOURCE.md.
• Most of the line count is the two lock JSON files.
• The Containerfile still resolves RPMs in the builder stage. Migrating it
  to consume the verified bundle is the next increment and is deliberately
  kept out of this PR.

Verification

python -m unittest tests.test_artifacts -v (11 tests) now runs in the lint
job. Lock validation commands documented in the README and acquisition guide
were executed against both architecture locks.

🤖 Generated with Claude Code

[joey-huckabee]

Rebuilt on current main (which now carries the #12 base/module fix) and refreshed both architecture locks.

Why the locks changed. They pinned openssl-libs 1:3.5.5-6.el9_8, the package CVE-2026-14456 affects. Landing them unchanged would have handed the hermetic build in the next increment a known-vulnerable closure — the stricter path reintroducing what the legacy one just fixed.

Reviewed lock diff (step 6 of docs/ARTIFACT-LIFECYCLE.md), identical on both architectures:

openssl             1:3.5.5-6.el9_8   -> 1:3.5.8-1.el9_8
openssl-libs        1:3.5.5-6.el9_8   -> 1:3.5.8-1.el9_8
systemd             0:252-67.el9_8.4  -> 0:252-67.el9_8.6
systemd-libs        0:252-67.el9_8.4  -> 0:252-67.el9_8.6
systemd-pam         0:252-67.el9_8.4  -> 0:252-67.el9_8.6
systemd-rpm-macros  0:252-67.el9_8.4  -> 0:252-67.el9_8.6

Invariant	Result
Packages added / removed	0 / 0 (79 -> 79)
Source packages	59 -> 59, 2 swapped
Signing identities	unchanged, both approved fingerprints
Repositories	unchanged (nginx-stable, ubi-9-baseos-rpms)
NGINX package	unchanged, nginx-2:1.30.4-1.el9.ngx
AMD64 vs ARM64	identical package names, versions, and source set

openssl is the intended RHSA-2026:67165 fix. systemd is incidental — it came with the refreshed base rather than being targeted, so it deserves a reviewer's attention even though it is a same-stream rebuild.

Resolution ran in a clean networked UBI 9 container; resolver output was not committed. artifacts/components.json is regenerated from these same locks in the component-accountability increment, so the inputs, both locks, and the inventory still land as one reviewed set before any release.