fix(build): three drill-driven fixes so the lane actually completes on a starter node

The first live build (Kaniko v1.24, 4 vCPU / 5.5 GiB node) walked the new
transport end to end and hit three real defects, each invisible to unit tests:

- The Job requested its FULL limits (2 CPU / 4Gi per container), so the build
  Pod never scheduled on the platform's own starter node: FailedScheduling /
  Insufficient memory, Pending forever. Requests are now a small floor
  (250m / 512Mi, never above a configured cap) while the limits stay the
  safety caps.
- Kaniko re-copies the Dockerfile out of the context and chowns/chmods it to
  the source owner; a 65532-owned context (the distroless felis image uid)
  fails that under the pod's dropped capabilities ('copying dockerfile:
  chown /kaniko/Dockerfile: operation not permitted'). The fetch container
  now extracts as root — the uid Kaniko already runs as — so the copy
  succeeds; the pod was root by necessity regardless.
- Trivy's DB fetch is exactly what the build egress lock denies: the scan
  step failed closed on mirror.gcr.io. New [registry] trivy_db_repository
  renders --db-repository, and docs/troubleshooting.md §8e now carries the
  verified mirror recipe (docker pull/tag/push of aquasec/trivy-db:2 into the
  internal registry; --insecure already covers its plain HTTP).

Verified live after this batch: fetch initContainer streamed the blob through
the API + netpol + token, Kaniko built and pushed registry.felis.svc:5000/
user-uploads/sub-<id>:latest, and Trivy scanned against the mirrored DB.

docs/deferred-seams.md

@@ -55,9 +55,12 @@ A grep across `*.md` and `*.go` returns both sets; only the Go ones are seams.
   filesystem view or object-store credentials. Kaniko/Trivy images are
   external-only by default; `[registry] kaniko_image / trivy_image /
   build_cpu_limit / build_mem_limit` override them for mirrored or air-gapped
-  installs, and Trivy's vulnerability DB download needs the same treatment (a
-  `package_source_cidrs` allowance or an internal `TRIVY_DB_REPOSITORY` mirror) or
-  the scan step fails closed on an egress-locked install.
+  installs. Trivy's vulnerability DB is the same story, and now has its own knob:
+  `[registry] trivy_db_repository` points `--db-repository` at an internal mirror
+  (recipe in docs/troubleshooting.md §8e). Left unset on an egress-locked box the
+  scan step fails closed — Kaniko pushes, Trivy exits on the DB download — which
+  is the correct fail direction but leaves the build unfinished, so the mirror is
+  part of a production build install.
 
 ## Built; only its I/O is unverifiable from this repo
 

docs/troubleshooting.md

@@ -408,14 +408,33 @@ url = "registry.felis.svc:5000"
 build_namespace = "felis-build"
 kaniko_image = "registry.felis.svc:5000/mirror/kaniko:v1.23.2"
 trivy_image  = "registry.felis.svc:5000/mirror/trivy:0.58.1"
+trivy_db_repository = "registry.felis.svc:5000/mirror/trivy-db:2"
 build_cpu_limit = "2"
 build_mem_limit = "4Gi"
 ```
 
 then restart `felis-api` (it renders the Job from this config). Unset fields keep
-the defaults. Note the user-modpack context topologies are a separate,
-still-open seam (see `docs/deferred-seams.md`); this section only makes the
-executors reachable.
+the defaults.
+
+`trivy_db_repository` is not optional on an egress-locked box. Trivy fetches its
+vulnerability DB from `mirror.gcr.io`/`ghcr.io` unless told otherwise, and the
+build egress policy denies those hosts — so the scan step fails closed
+(`failed to download vulnerability DB`) and NO build ever completes, even though
+Kaniko pushed the image. Mirror the DB into the internal registry once:
+
+```
+# On a host with internet + docker access to the cluster's registry
+# (add its address to the daemon's insecure-registries first; the registry
+# serves plain HTTP):
+#   docker pull mirror.gcr.io/aquasec/trivy-db:2
+#   docker tag  mirror.gcr.io/aquasec/trivy-db:2 <registry-addr>:5000/mirror/trivy-db:2
+#   docker push <registry-addr>:5000/mirror/trivy-db:2
+```
+
+The Job's Trivy container already runs with `--insecure`, so the internal
+registry's plain HTTP works for the DB pull exactly as it does for the scanned
+image. Re-mirror the tag periodically (Trivy refreshes the DB several times a
+day upstream; a stale mirror only means stale CVE data, never a failed gate).
 
 ---