fix(cloudformation): unique generated names, and replacement that can roll back

[Neaox]

Found during alpha.26 release smoke testing, when a real cdk deploy failed. Two coupled defects.

1. Unnamed resources collided

lambda CreateFunction: HTTP 409:
{"__type":"ResourceConflictException","message":"Function already exist: OvercastSmokeCsc-Function"}

Physical names came from the stack alone:

funcName = fmt.Sprintf("%s-Function", rCtx.StackName)

So every unnamed resource of a type in a stack got the same name and the second collided with the first. CDK almost never sets FunctionName — it lets CloudFormation generate a physical ID — so a stack with two Lambda functions could not deploy at all. Very likely the cause of the long-standing cdk/cdk-lifecycle/Deploy compat failure.

Fourteen handlers shared the fallback, so this was never Lambda-only: queues, tables, topics, buckets, roles, policies, instance profiles, secrets, log groups, log streams, SSM parameters, layer versions and event buses all collided the same way. Two unnamed queues resolved to the identical URL.

Names now follow CloudFormation's own shape — {StackName}-{LogicalID}-{RANDOM} — via a single resolveContext.generatedName(), capped per service (generatedNameWithin) since adding the logical ID made them longer. Truncation keeps the unique suffix, because that is what guarantees uniqueness.

2. A failed replacement destroyed the resource

Replacement deleted the old resource before creating the new one, and rollbackUpdate only ever deleted resources — it had no path to restore one. So a replacement whose create failed left the resource gone entirely, with nothing to roll back to.

The test for exactly that scenario, run against the old code:

--- FAIL: TestUpdateStack_failedReplacementKeepsTheOriginalResource
    expected queue "replace-rollback-v1" to exist; queues=[]

Both the original and the replacement gone. Real CloudFormation creates the replacement first and deletes the original only after the whole update commits, which is what makes rollback possible.

Now:

• Replacement creates first and returns the old physical ID to the caller.
• Old resources are deleted in a cleanup phase that runs only once every resource updated successfully.
• On failure, rollback deletes the replacement and keeps the original.

This is what the random name component is for: the two must coexist for the window between create and cleanup.

3. Fallout caught while doing the above

Both IAM policy handlers compared a freshly generated name against the stored one to detect a rename. With a random suffix that differs every time, which would have forced a replacement on every update of an unnamed policy. An unnamed resource now keeps the name it was generated with — CloudFormation does not rename one on update.

Verification

Failing-first, all four new tests fail on the old code with the symptoms above.

Real cdk deploy of a stack with two unnamed functions and two unnamed queues — the exact case that failed:

✅  OvercastUnnamed
OvercastUnnamed.AlphaName  = OvercastUnnamed-Alpha5E55F45A-52LDPKUAF4Z8
OvercastUnnamed.BetaName   = OvercastUnnamed-BetaC60672CA-HU8OICQ1P7AR
OvercastUnnamed.FirstUrl   = .../OvercastUnnamed-First8D4707F1-S1EHJD3YC0K6
OvercastUnnamed.SecondUrl  = .../OvercastUnnamed-Second394350F9-ZXDCINM9X1SU

Both functions invoke and return their own payloads ({"from":"alpha"} / {"from":"beta"}), so they are genuinely separate resources.

go vet ./...        # clean
go test ./...       # all pass

Two existing tests hardcoded the old generated names and now derive them from the stack output instead, since a generated name is unpredictable by design.

Note for reviewers

iamPolicyHandler builds its physical ID as {StackName}-{policyName}, so an unnamed policy's ID now reads {Stack}-{Stack}-{Logical}-{RANDOM}. It is self-consistent — Update strips the prefix to recover the name — and I left the format alone rather than change a stored-state shape in this PR, but it is worth tidying.