fix(build): mirror the Trivy Java DB — jar-bearing builds failed closed at the scan gate (#72)

docs/deferred-seams.md

@@ -57,10 +57,12 @@ A grep across `*.md` and `*.go` returns both sets; only the Go ones are seams.
   build_cpu_limit / build_mem_limit` override them for mirrored or air-gapped
   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.
+  (recipe in docs/troubleshooting.md §8e); `trivy_java_db_repository` does the
+  same for the Java DB, which Trivy fetches so soon as the scanned image contains
+  a jar — i.e. for every real modpack build. 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
+  mirrors are part of a production build install.
 
 ## Built; only its I/O is unverifiable from this repo
 

docs/troubleshooting.md

@@ -411,6 +411,7 @@ build_namespace = "felis-build"
 kaniko_image = "registry.felis.svc:5000/mirror/kaniko-executor:v1.24.0"
 trivy_image  = "registry.felis.svc:5000/mirror/trivy:0.74.0"
 trivy_db_repository = "registry.felis.svc:5000/mirror/trivy-db:2"
+trivy_java_db_repository = "registry.felis.svc:5000/mirror/trivy-java-db:1"
 build_cpu_limit = "2"
 build_mem_limit = "4Gi"
 ```
@@ -423,10 +424,13 @@ through the loopback hostPort the registry Deployment binds (docker treats
 ```sh
 docker pull gcr.io/kaniko-project/executor:v1.24.0   # any versions you pin
 docker pull aquasec/trivy:0.74.0
+docker pull mirror.gcr.io/aquasec/trivy-java-db:1
 docker tag gcr.io/kaniko-project/executor:v1.24.0 127.0.0.1:5000/mirror/kaniko-executor:v1.24.0
 docker tag aquasec/trivy:0.74.0                   127.0.0.1:5000/mirror/trivy:0.74.0
+docker tag mirror.gcr.io/aquasec/trivy-java-db:1  127.0.0.1:5000/mirror/trivy-java-db:1
 docker push 127.0.0.1:5000/mirror/kaniko-executor:v1.24.0
 docker push 127.0.0.1:5000/mirror/trivy:0.74.0
+docker push 127.0.0.1:5000/mirror/trivy-java-db:1
 ```
 
 From another machine, port-forward the registry instead (`kubectl -n felis
@@ -469,6 +473,13 @@ 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).
 
+`trivy_java_db_repository` is the same story one step lazier: Trivy downloads
+the Java DB on demand the first time it scans an image containing Java
+artifacts — every real modpack — and that download fails closed too. Mirror
+`mirror.gcr.io/aquasec/trivy-java-db:1` alongside the vulnerability DB (commands
+above); the Java DB refreshes far less often than the vulnerability DB, so a
+one-off mirror is usually fine.
+
 ---
 
 ## 9. Registry push/pull failures (spec §15)