GCP deploys must preserve the selected capacity profile

[Brad-Edwards]

Problem\n\nThe GCP bootstrap path renders the selected shared-service capacity profile through Helm, but a later normal release applies the static Kustomize workload manifests without reapplying that profile. Kubernetes retains the capacity-profile label and HPA, while the workload resource requests and limits silently revert to static-base values.\n\nThis can leave a deployment reporting one capacity profile while running materially smaller portal, guacd, and client resources. Under ordinary participant traffic, the portal can reach its container memory limit and restart, disrupting HTTP and WebSocket service.\n\n## Expected behavior\n\nEvery normal GCP release must project the installation-selected capacity profile into the exact manifest it applies. The applied replicas, workload resources, termination settings, runtime concurrency values, and profile identity must remain one coherent contract.\n\n## Acceptance criteria\n\n- The normal GCP release renderer resolves the configured capacity profile.\n- Portal, guacd, and Guacamole client deployments receive the profile's replicas, resources, and termination grace.\n- The runtime ConfigMap receives the profile's runtime values.\n- Applied workload metadata retains the matching profile identity.\n- Missing expected workload/config resources fail closed.\n- Tests prove a normal release cannot retain a profile label while reverting to static-base resources.\n- Operator documentation states that normal releases reapply the profile projection.