fix(delete-user-data): kit/extension parity – invalid .env values deploy and silently delete less data #3258

delete-user-data kit/extension parity. Priority: high. Invalid config deploys fine and then deletes less data than intended.

Difference

• Extension: rejects invalid values at install time: a select value that isn't an option, or a value that fails validationRegex.
• Kit: firebase-tools only validates params it prompts for. Values already in .env are used exactly as written, so invalid values deploy and then quietly misbehave.

Note: the extension also accepts an option label (Recursive, Yes). It stores the label as-is, and its runtime then misbehaves the same way the kit does. That's an existing extension bug, not a parity gap.

Reproduced

• Extension: the validateOnly instances API rejected every value in the table, e.g. param provided with invalid option RECURSIVE, must be one of recursive, shallow.
• Kit: deployed with FIRESTORE_DELETE_MODE=RECURSIVE and ENABLE_AUTO_DISCOVERY=true. Deleting a user removed users/<uid> but left users/<uid>/sub/s1, and a doc with uid: <uid> was never discovered.

Code

• Extension: options and regexes in extension.yaml#L115-L218.
• Kit: the same options and regexes exist only as prompt input (config.ts#L50-L130). The runtime compares values without checking them (config.ts#L215, handlers.ts#L73, #L252).

Resolution

Validate these five params at module load, next to assertRequiredParams() (config.ts#L226-L260), so deploy-time discovery fails the way an extension install does. Reject select values outside the option values, and reject values that fail the extension's regexes. Rejecting labels too would be stricter than the extension, and safer. Same pattern as assertRequiredParams() and storage-resize-images' validatePathListsFromEnv(); #3169 (open, into next) proposes similar checks for IMAGE_TYPE. Every kit gets .env values the same way, so other kits likely have the same gap.