fix(functions): normalize migrated extension memory to valid MemoryOption

[wandamora]

Description

When exporting Firebase Extensions for migration to Cloud Functions kits (ext:export --mode functions), memory settings are mapped to the EXT_MIGRATED_SYSTEM_MEMORY environment variable. However:

1. Incompatible Memory Format / Missing Unit Suffix: Extensions v2 system memory parameters are formatted without the trailing B (e.g. "256Mi", "512Mi", "1Gi"), and v1 parameters are integers representing megabytes (e.g. "256", "1024"). Directly assigning these values produces invalid MemoryOption values for firebase-functions/v2's setGlobalOptions, which expects "MiB" / "GiB" suffixes (e.g. "256MiB", "1GiB").
2. Conflicting V1 and V2 System Parameters: When an extension contains both v1 and v2 memory parameters (or when spec defaults and live parameters co-exist), memory parameters could overwrite each other arbitrarily in functionsEnvFromInstance.

Changes:

• Added memoryToMb and resolveMigratedMemory in src/extensions/export.ts to convert memory values to MB and safely resolve multiple memory parameters by selecting the higher memory allocation (preventing runtime OOMs when migrating multi-function extensions to a shared global kit configuration).
• Added parseMemory in src/extensions/export.ts to normalize raw memory values into valid Cloud Functions v2 MemoryOption strings ("256MiB", "512MiB", "1GiB").
• Updated functionsEnvFromInstance to normalize EXT_MIGRATED_SYSTEM_MEMORY upon export, ensuring the generated .env.<projectId> file contains standard, unambiguous units and keeping user-facing kit migration templates free of parsing boilerplate.
• Added comprehensive unit tests in src/extensions/export.spec.ts covering memory conversion, normalization permutations, conflict resolution, and environment generation.

Scenarios Tested

• Ran npx mocha src/extensions/export.spec.ts (all 62 tests passing):
  • Verified memoryToMb correctly parses plain megabytes ("256", "1024"), Mi/MiB ("256Mi", "512MiB"), Gi/GiB ("1Gi", "2GiB"), decimals ("0.5Gi"), negative numbers, and invalid inputs.
  • Verified parseMemory correctly maps all standard memory options from 128MiB to 32GiB, normalizes 1024Mi -> 1GiB and 2048Mi -> 2GiB, accurately parses 1GB, 1G, and 0.5Gi, and returns undefined for non-standard/invalid inputs.
  • Verified resolveMigratedMemory handles missing params, single v1/v2 params, selects the higher memory allocation when both are present, and falls back to spec defaults.
  • Verified functionsEnvFromInstance normalizes EXT_MIGRATED_SYSTEM_MEMORY to valid MemoryOption values for v1-only, v2-only, equal memory, v1-higher, and spec-default fallback cases.
• Manually verified ext:export -> kits:install flow to ensure parameters apply cleanly within .env and functions.yaml.

Sample Flow

firebase functions:kits:install --package @firebase-function-kits/firestore-bigquery-export@0.0.2-rc.9 --template migration --no-configure
firebase ext:export --mode functions -k inst1 --instance firestore-bigquery-export
firebase deploy --only functions:inst1

[gemini-code-assist]

Code Review

This pull request adds memory resolution logic for migrated Extension instances, ensuring that the highest memory value is selected when both V1 and V2 parameters are present, and normalizes memory strings for global options. The reviewer provided valuable feedback pointing out critical bugs in the parseMemory implementation regarding decimal values and standard units, as well as suggesting a more robust regex in memoryToMb to handle optional whitespace.

[ajperel]

Please get Victor to review, he's the expert, but the overall approach seems good (I'm trusting you on what formats come out of extensions and are accepted by setGlobalOptions). Leaving some feedback from Joe's skill that seem ok.