fix(gen2-migration): fix lambda authorizer import and REGION hardcode - REVIEW LAST

[dgandhi62]

NOTE TO ME: To merge this, first rebase onto both #14487 and #14517 first, then run UPDATE_SNAPSHOTS=1 yarn test to reconcile snapshots and resolve test file conflicts

Solves #14813.

Issue Summary

Two bugs in the Gen1-to-Gen2 migration generate step: (1) when a GraphQL API uses a Lambda authorizer, the generated data/resource.ts references the function variable without importing it, and (2) the generated function/resource.ts files hardcode the REGION environment variable to the literal resolved value (e.g. 'us-east-1') instead of resolving it dynamically. Since existing Gen 1 function code reads process.env.REGION at runtime, dropping it entirely would break those functions — so the fix emits REGION: process.env.AWS_REGION ?? '' to resolve dynamically from the Lambda-injected AWS_REGION.

Reasoning

1. Lambda authorizer import: When a GraphQL API uses a Lambda authorizer as an additional auth mode, the generated data/resource.ts emits lambdaAuthorizationMode: { function: myAuthFunc } but never imports myAuthFunc. The function variable is defined in ../function/myAuthFunc/resource.ts and needs an explicit import.
2. Read data.renderer.ts — found render() which builds the import list but had no logic to inspect authorization modes for Lambda function references.
3. Added extractLambdaFunctionName() to DataRenderer which reads the authorizationModes config, checks both defaultAuthentication and additionalAuthenticationProviders for AWS_LAMBDA type, and returns the function name. The render() method now emits the missing import when a Lambda authorizer is found.
4. REGION hardcode: The renderEnvironment() method in function.renderer.ts was passing REGION through as a literal string (REGION: 'us-east-1'). The initial fix dropped it entirely, reasoning that AWS_REGION is auto-injected by Lambda. But Gen 1 function code (e.g. new CognitoIdentityProviderClient({ region: process.env.REGION })) reads process.env.REGION, not process.env.AWS_REGION — so dropping it would cause those SDK clients to receive undefined for the region.
5. The correct fix emits REGION: process.env.AWS_REGION ?? '' — a dynamic expression that resolves at runtime from the Lambda-injected AWS_REGION, keeping backward compatibility with existing function code.

Solution

• data.renderer.ts — Added extractLambdaFunctionName() that inspects authorization modes for Lambda authorizer config and returns the function name. render() now emits an import for the Lambda function when present.
• data.generator.test.ts — Updated inline snapshot for the Lambda auth mode test to verify the import is emitted.
• function.renderer.ts — Changed the REGION handling from if (key === 'REGION') continue (skip entirely) to emitting REGION: process.env.AWS_REGION ?? ''. This generates a dynamic reference instead of a hardcoded literal or omission.
• function.generator.test.ts — Updated two REGION tests: one verifying REGION renders as process.env.AWS_REGION ?? '' alongside other env vars, and one verifying the environment block is still emitted when REGION is the only env var.
• 18 golden migration app snapshots — Updated all function/*/resource.ts snapshots to reflect the new dynamic REGION output (REGION: process.env.AWS_REGION ?? '' instead of REGION: 'us-east-1').

Example

Input (Gen 1 — deployed function config):

{
  "FunctionName": "admin-main-abc",
  "Environment": {
    "Variables": {
      "ENV": "main",
      "REGION": "us-east-1"
    }
  }
}

Output — before fix (resource.ts):

import { defineFunction } from '@aws-amplify/backend';

export const admin = defineFunction({
  environment: { ENV: `${branchName}`, REGION: 'us-east-1' },
});

Output — after fix (resource.ts):

import { defineFunction } from '@aws-amplify/backend';

export const admin = defineFunction({
  environment: { ENV: `${branchName}`, REGION: process.env.AWS_REGION ?? '' },
});