Fix intermittent Lambda 409 when adding Function URL permissions

[AppleDannyClegg]

Fix intermittent Lambda 409 when adding Function URL permissions

Problem

Deploying an SSR site (Nextjs, Astro, SolidStart, …) intermittently fails with:

operation error Lambda: AddPermission, https response error StatusCode: 409,
ResourceConflictException: The function could not be updated due to a concurrent
update operation.

It's non-deterministic and hits fresh/ephemeral stacks (e.g. per-PR preview
environments) far more often than re-deploys. Retrying the deploy succeeds.

Cause

AWS Lambda serialises mutating control-plane operations per function: after any
update the function is briefly LastUpdateStatus: InProgress, and a second
mutating call in that window is rejected with a 409.

During a deploy two resources mutate the same function and, with no ordering
between them, Pulumi runs them concurrently:

• aws.lambda.FunctionUrl — created in Function.createUrl()
  (CreateFunctionUrlConfig), and
• aws.lambda.Permission with action: "lambda:InvokeFunctionUrl".

For the OAC path the permission is created in SsrSite and depends only on the
function — not on the function URL. It can't depend on the URL because the
FunctionUrl resource isn't exposed on Function.nodes (only role,
function, logGroup, eventInvokeConfig). So AddPermission races
CreateFunctionUrlConfig and lands mid-update. Fresh stacks hit it more often
because the function and its URL are created together in a single run.

Fix

Serialise the permission after the function URL:

• expose the FunctionUrl resource on Function.nodes.url, and
• add dependsOn on it to every lambda.Permission that grants URL access —
  both the ones created inside Function.createUrl() (public + router modes)
  and the OAC/CloudFront ones created in SsrSite (server functions and the
  image optimizer).

dependsOn only changes the Pulumi dependency graph, so existing permission
resources are updated in place — no replacement, no downtime.

Testing

• tsc --noEmit passes.
• platform test suite: all component tests pass (the only failures are a
  pre-existing Node-version incompatibility in unrelated suites — alb,
  bucket, service-alb — that error on @types/node resolution /
  ERR_TRACE_EVENTS_UNAVAILABLE, unaffected by this change).
• Recommended before merge: a deploy of an SSR site in oac /
  oac-with-edge-signing and none protection modes (and a multi-region
  deploy) to confirm the 409 no longer occurs and that no permission resources
  are replaced on an in-place update.

Notes / possible follow-ups

The same class of concurrent-mutation race can in principle affect other
per-function operations that run alongside URL/permission creation (e.g.
provisioned-concurrency config, or an environment update). Those are out of
scope here; happy to look at them separately if maintainers think it's worth it.