fix(lambda): discover permissions on published versions and aliases

[JeroenSoeters]

Summary

• AWS::Lambda::Permission discovery only found statements on the bare function's resource policy. Lambda keeps a separate policy per qualifier, and the CloudControl list handler returns just the unqualified one, so a permission granted against a published version's or alias's ARN (the shape API Gateway and Lambda@Edge wiring uses) was invisible to discovery. This surfaced as soon as discovery for the type was enabled: the conformance suite that attaches a permission to a published version's qualified ARN fails its discovery phase because the awaited id can never appear in the list.
• List now goes through a custom provisioner that walks every policy scope via the Lambda control plane: GetPolicy on the function, on each published version (ListVersionsByFunction, paginated, $LATEST skipped since it shares the unqualified policy), and on each alias (ListAliases). Each statement emits the same ARN|Sid composite id the CloudControl CRUD path produces, so discovered and managed permissions resolve to identical ids. A deleted function yields an empty list, a scope with no policy is skipped, and the client carries the discovery-grade retry budget that registry dispatch bypasses.

Verification

• Six unit tests cover the multi-scope enumeration, version pagination, missing-filter and deleted-function handling, and error propagation; make test-unit, make lint, make verify-schema, make build all pass.
• Targeted conformance for lambda-version-ref (the failing qualified case) and lambda-permission (unqualified regression guard) dispatched from this branch; results will be linked in a comment.

[JeroenSoeters]

Conformance evidence: lambda-version-ref and lambda-permission, CRUD and discovery suites, all phases passing. The version-ref discovery phase, structurally unable to pass before this change, completes in 2m12s with the qualified permission found; the unqualified case stays green.