SBOM-WP-0005-T01: record wave-2 preparation (not applied)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 276069@bnt-lap001
Assistant-Session: 2e192b3d-b3e8-4403-94d4-d55a2c8b476c

workplans/SBOM-WP-0005-wave2-resource-right-sizing.md

@@ -43,6 +43,8 @@ Source and container detail:
 
 - `sbom-nexus/sbom-nexus`: Deployment `sbom-nexus`, container `sbom-nexus`, `rapp-sbom-nexus/manifests/runtime.yaml` (25m/64Mi) — the deploy source lives in rapp-sbom-nexus. Memory p95 80Mi is above the 64Mi request but below the 64Mi change threshold; the owner may raise it to 96Mi in the same change.
 
+**Prepared 2026-10-21 (wave-2 worker W1a; not applied).** Live owner is a server-side apply with field manager `rapp-sbom-nexus` (`make deploy` in rapp-sbom-nexus). Change: rapp-sbom-nexus `bd3eff4`, `manifests/runtime.yaml` CPU request 25m → 10m; memory 64Mi and limits unchanged. The optional 96Mi raise was not taken. Server-side diff of the rendered runtime.yaml: only `resources.requests.cpu`. The migration Job is gone live; `make deploy` would recreate and wait on it, so apply only the runtime part: `make render && kubectl apply --server-side --force-conflicts --field-manager=rapp-sbom-nexus -f .rendered/runtime.yaml` (local kubectl rather than the Makefile's ssh path). The pre-existing forge-URL test failure is unrelated to this change.
+
 Evidence: resource-control `docs/evidence/2026-10-21-node-allocation-review/2026-10-21-node-budget.md` (+ `.json`, commit `3d9b1bd`). Rule: CPU = max(floor, p95x1.5, peakx0.5) rounded up to 5m; memory request = 7d p95 working set x1.15 (only when the change is at least 64Mi).
 
 Steps: