ci: use a unique identifier per integration-suite attempt

[jchrostek-dd]

Overview

Integration-suite deploys intermittently fail at the CDK deploy step, before any test runs, with:

Automatic import of existing resource /aws/lambda/integ-<sha>-<suite>-... needs a DeletionPolicy of 'Retain' or 'RetainExceptOnCreate'.

Root cause. The test stack is named only after the commit SHA (integ-<sha>-<suite>) and the job has retry: 2, so retries reuse the same name. The CDK LogGroup is already wired into each function, but LoggingConfig only points the function at a log group name — it doesn't keep that name alive. When a retry's delete-stack (run in after_script, even on failure) deletes a function's log group while another attempt's function is still being invoked, the Lambda service recreates the group as an unmanaged, never-expire group. That group is never owned by CloudFormation, so it survives cdk destroy and blocks the next attempt — which reuses the same name and tries to auto-import it (--import-existing-resources), but the construct uses RemovalPolicy.DESTROY, not Retain, so the import is rejected. ~990 such orphans had accumulated (~600 from the auth suite, whose slow SnapStart test retries most often).

Fix. Append CI_JOB_ID to the identifier so every attempt — automatic retry, manual job retry, or pipeline retry — gets unique stack, function, and log group names. Names never recur, so a leftover group from a prior attempt can never collide with a later deploy. CI_JOB_ID is unique per job instance (unlike CI_PIPELINE_ID, which is reused on a pipeline retry) and is available in both script and after_script, so teardown still deletes the right stack.

CI-only change; no application code or IAM changes.

Testing

• Verified in the serverless sandbox that the orphan is caused by the Lambda service recreating a deleted log group on invocation (deleting a managed group and invoking the function recreates it as never-expire), so wiring the logGroup prop — the originally-assumed fix — does not prevent it; eliminating name reuse does.
• Confirmed the longest function name (integ-<sha>-otlp-response-validation-lambda) stays under Lambda's 64-char limit after adding -<CI_JOB_ID> (~57 chars).
• Rendered the pipeline template with gomplate --config .gitlab/config.yaml and validated the generated YAML parses.
• Immediate unblock: deleted the orphaned integ-40fb9899-auth-{java,node} groups from the referenced failing job.