fix(aws): add InvokeFunction permission for public Function URLs

[bruno-espino]

Fixes #6198

What this PR changes

• When sst.aws.Function is configured with url.authorization: "none", SST now adds an explicit resource-based permission:
  • action: "lambda:InvokeFunction"
  • principal: "*"
  • function: <function name>

This matches the AWS console guidance for public Function URLs and fixes existing stacks without requiring a manual policy edit.

Notes / follow-ups

• The AWS console scopes the InvokeFunction statement with lambda:InvokedViaFunctionUrl=true.
• This PR adds the minimal required permission via aws.lambda.Permission and includes an inline comment to remove it after we migrate to @pulumi/aws v7 (where Lambda/provider behavior matches the current
  console policy).

Repro

new sst.aws.Function("Api", {
  handler: "src/lambda.handler",
  url: { authorization: "none" },
});

Deploy and hit the function URL; before this change you'll get 403

[jakehewitt]

Tested this PR and verified it works

[jakehewitt]

I might not have tested this correctly but I don't think upgrading to @pulumi/aws v7 fixes this automatically. I tested by cloning #6259 and upgrading from v7.12.0 → v7.16.0 (which includes terraform-provider-aws v6.28.0 where hashicorp/terraform-provider-aws#44829 was resolved), but the issue persisted without these changes.

[bruno-espino]

Interesting, the fix for v7 was an assumption from my side, I didn't test it.

[bruno-espino]

@vimtor if jake cloned from #6259 looks like this is still an issue

[vimtor]

let's wait on merging #6259 first to see if the warning disappears

[vimtor]

thanks for your contribution @bruno-espino

closed in favor of #6400 which contains the fix for protection: "oac" mode too

let's wait on merging #6259 first to see if the warning disappears

i've changed my mind on this since i don't want new users to wait on the v7 to get merged for this common use-case to work