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