(gen2-migration): `generate` has bug in lambda authorizer for additional auth mode

### How did you install the Amplify CLI?

_No response_

### If applicable, what version of Node.js are you using?

_No response_

### Amplify CLI Version

na

### What operating system are you using?

na

### Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.

na

### Describe the bug

### Description

When migrating an Amplify Gen1 app that uses a Lambda authorizer as an additional auth mode on a GraphQL API, the generated Gen2 `amplify/data/resource.ts` references the Lambda function in `lambdaAuthorizationMode` without importing it. This results in a build failure.

### Gen1 State

The Gen1 app had a GraphQL API (`AppSync`) configured with:
- **Default auth**: API Key (7-day expiry)
- **Additional auth**: AWS Lambda authorizer (`graphQlLambdaAuthorizerd351d098`) with a 300s TTL

This was defined across multiple Gen1 config files:

**`amplify/backend/api/lambdaauthconfig/cli-inputs.json`**:
```json
{
"additionalAuthTypes": [
{
"mode": "AWS_LAMBDA",
"lambdaFunction": "graphQlLambdaAuthorizerd351d098",
"ttlSeconds": "300"
}
]
}
```

**`amplify/backend/backend-config.json`** linked the API to the function and both resources deployed correctly.

The GraphQL schema used both auth modes:
```graphql
type Todo @model @auth(rules: [
{ allow: public, provider: apiKey },
{ allow: custom }
]) {
id: ID!
name: String!
description: String
}
```

### Issue in Generated Gen2 Code

The generated `amplify/data/resource.ts` references `graphQlLambdaAuthorizerd351d098` in the `lambdaAuthorizationMode` config but does not include an import statement for it:

```typescript
import { defineData } from '@aws-amplify/backend';

const schema = `...`;

export const data = defineData({
authorizationModes: {
defaultAuthorizationMode: 'apiKey',
apiKeyAuthorizationMode: { expiresInDays: 7, description: 'sdfgadfv' },
lambdaAuthorizationMode: {
function: graphQlLambdaAuthorizerd351d098, // ❌ undefined — no import
timeToLiveInSeconds: 300,
},
},
schema,
});
```

The function is correctly defined in `amplify/function/graphQlLambdaAuthorizerd351d098/resource.ts` and correctly imported in `amplify/backend.ts`, but the import is missing in `data/resource.ts`.

### Expected Behavior

The migration should generate `data/resource.ts` with the necessary import:

```typescript
import { defineData } from '@aws-amplify/backend';
import { graphQlLambdaAuthorizerd351d098 } from '../function/graphQlLambdaAuthorizerd351d098/resource';
```

### Impact

- The Gen2 app will fail to build/deploy
- The Lambda authorizer auth mode is non-functional
- The `@auth(rules: [{ allow: custom }])` rule on the Todo model cannot be enforced

### Steps to Reproduce

1. Create a Gen1 Amplify app with a GraphQL API
2. Add API Key as default auth and Lambda as an additional auth type
3. Run the Gen1 to Gen2 migration
4. Observe that `amplify/data/resource.ts` references the Lambda function without importing it

---

## Bug: Gen1 to Gen2 migration hardcodes REGION environment variable instead of using dynamic resolution

### Description

When migrating an Amplify Gen1 app to Gen2, the generated function `resource.ts` files hardcode the `REGION` environment variable to a specific region string (`us-east-1`) instead of resolving it dynamically at deploy time. This causes incorrect behavior if the app is deployed to a different region.

### Gen1 State

In Gen1, both Lambda functions had their `REGION` environment variable set dynamically via CloudFormation intrinsic functions:

**`graphQlLambdaAuthorizerd351d098-cloudformation-template.json`**:
```json
"Environment": {
"Variables": {
"ENV": { "Ref": "env" },
"REGION": { "Ref": "AWS::Region" }
}
}
```

`AWS::Region` is a CloudFormation pseudo-parameter that resolves to whatever region the stack is deployed in. This ensured the function always had the correct region regardless of deployment target.

### Issue in Generated Gen2 Code

Both generated function `resource.ts` files hardcode the region:

**`amplify/function/graphQlLambdaAuthorizerd351d098/resource.ts`**:
```typescript
export const graphQlLambdaAuthorizerd351d098 = defineFunction({
environment: { ENV: `${branchName}`, REGION: 'us-east-1' }, // ❌ hardcoded
});
```

**`amplify/function/recurring/resource.ts`**:
```typescript
export const recurring = defineFunction({
environment: { ENV: `${branchName}`, REGION: 'us-east-1' }, // ❌ hardcoded
});
```

### Expected Behavior

The migration should either:
1. Use the CDK `Stack.of(this).region` to resolve the region dynamically, or
2. Omit the `REGION` variable entirely since `process.env.AWS_REGION` is automatically available in all Lambda execution environments

### Impact

- The Lambda authorizer uses `process.env.AWS_REGION` to construct ARNs for `deniedFields`. If `REGION` is hardcoded incorrectly, the `AWS_REGION` env var still works, but the custom `REGION` env var would be misleading if any code references it.
- Deploying to any region other than `us-east-1` would result in an incorrect `REGION` environment variable.

### Steps to Reproduce

1. Create a Gen1 Amplify app with Lambda functions in any region
2. Run the Gen1 to Gen2 migration
3. Observe that `REGION` is hardcoded to `us-east-1` in the generated `resource.ts` files

### Expected behavior

na

### Reproduction steps

na

### Project Identifier

_No response_

### Log output

```
# Put your logs below this line

```

### Additional information

_No response_

### Before submitting, please confirm:

- [x] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
- [x] I have removed any sensitive information from my code snippets and submission.

Start by tracing the Gen1-to-Gen2 migration output for amplify/data/resource.ts and the generated amplify/function/*/resource.ts files, comparing them with the Gen1 cli-inputs.json and CloudFormation template shown here. The migration should emit the Lambda authorizer import and avoid hardcoding REGION in both generated functions. Validate that the generated app builds and that deployment to a region other than us-east-1 preserves correct region behavior.

Written by the indexing model from the issue text.