chore(cleanup): delete cmd/cleanup-lambda and its unused deploy modules

.github/workflows/ci.yml

@@ -435,7 +435,8 @@ jobs:
         # in the three-leg layout): api 87s, config 85s, auth 62s, server
         # 55s, purchase 53s, migrations 64s, and the rest 95s together
         # (testhelpers 32s, cleanup-lambda 15s, database 15s, scheduler 12s,
-        # analytics 12s, commitmentopts 9s). api is the floor, as one package
+        # analytics 12s, commitmentopts 9s; cleanup-lambda was deleted in
+        # #357, so the rest is about 80s now). api is the floor, as one package
         # is never split; migrations and the rest run side by side within it.
         include:
           - shard: api

.gitignore

@@ -96,7 +96,6 @@ sanity_report*.json
 # Compiled binaries
 cudly-final
 cudly-test
-cleanup-lambda
 /server
 /lambda
 

.trivyignore

@@ -59,21 +59,6 @@ AVD-AWS-0136
 # in the private subnets and routes egress through the NAT.
 AVD-AWS-0164
 
-# Azure Function app HTTPS enforcement.
-# Justification: the cleanup Function in
-# terraform/modules/compute/azure/cleanup-function/ is invoked by
-# Azure-internal triggers (timers + queue), never directly by external
-# HTTP. https_only=true would still be correct hygiene; tracked as a
-# follow-up to set explicitly.
-AVD-AZU-0004
-
-# Azure storage account network rules default allow.
-# Justification: the cleanup function's storage account is in the
-# same vnet as the function and is firewall-restricted at the Azure
-# resource-group level. The trivy ID still trips because the network
-# rules block isn't declared in the resource itself.
-AVD-AZU-0012
-
 # Azure Key Vault network ACL default action.
 # ID: AZU-0013 (surfaced by trivy v0.70.0; v0.69.3 did not report this ID).
 # Justification: the vault is in terraform/modules/secrets/azure/main.tf and
@@ -100,18 +85,6 @@ AZU-0047
 # entry looks stale. Drop it once a Trivy config scan without it is clean.
 GCP-0015
 
-# GCP Cloud Storage bucket: cleanup Cloud Function source bucket.
-# ID: GCP-0001 (surfaced by trivy v0.70.0; v0.69.3 did not report this ID).
-# Justification: the only GCS bucket in the GCP deployment is the cleanup
-# Cloud Function source bucket (terraform/modules/compute/gcp/cleanup-function/main.tf).
-# This bucket is NOT public: it has uniform_bucket_level_access = true and
-# public_access_prevention = "enforced". Trivy may still flag the resource if
-# it does not recognise the public_access_prevention attribute.
-# The GCP frontend is served from Cloud Run (not a GCS bucket), so no frontend
-# build artifacts -- including source maps (*.map, produced by hidden-source-map
-# in webpack.config.js) -- are uploaded to any GCS bucket.
-GCP-0001
-
 # Go dependency vulnerability (trivy fs) suppressions live in
 # .trivyignore.yaml, where each entry is scoped to one module by purl.
 # Keep this file for config-scan IDs only.

CHANGELOG.md

@@ -79,6 +79,14 @@ are the full record until the next release.
   Lambda or Fargate) instead; see `docs/DEPLOYMENT.md`. The target-account role
   templates (`cloudformation/stacks/CUDly-CrossAccount` and the federation
   CloudFormation templates under `iac/federation/`) are unchanged (#1432)
+- The standalone cleanup job `cmd/cleanup-lambda` and its three deploy modules
+  (`terraform/modules/compute/aws/cleanup-lambda`,
+  `terraform/modules/compute/gcp/cleanup-function` and
+  `terraform/modules/compute/azure/cleanup-function`). No environment root used
+  the modules. The job only deleted executions whose `expires_at` had passed,
+  and no code path sets that column, so it never deleted an execution. The server's
+  `cleanup` scheduled task (`CleanupOldExecutions`) already covers execution and
+  session retention; see "Database Cleanup Jobs" in `docs/DEPLOYMENT.md` (#357)
 
 ### Fixed