fix(schema-generator): sanitize database identifiers in TypeScript output path

[svidgen]

Summary

Sanitizes database column names and enum type names in the TypeScript data schema output path, matching the existing cleanMappedName behavior in the GraphQL-SDL output path.

Problem

The TypeScript schema generator passed raw database column names and enum type names directly to ts.factory.createIdentifier(), which emits them as bare JavaScript identifiers without any sanitization. Names containing special characters (parentheses, brackets, quotes, etc.) could produce invalid or unsafe TypeScript output.

Changes

• Add sanitizeIdentifier() helper that strips leading non-alphabetic characters and replaces non-alphanumeric characters with underscores (matching cleanMappedName from the GraphQL-SDL path)
• Use createStringLiteral instead of createIdentifier for field property names in createProperty()
• Use createStringLiteral instead of createIdentifier for enum type property names in createEnums()
• Sanitize enum type names in a.ref() calls for consistency between the enum definition and its references
• Fix enum deduplication logic to work with StringLiteral property names (uses .text instead of .escapedText)

Defense in Depth

This is a defense-in-depth measure. The TS output path should apply the same sanitization as the GraphQL-SDL path to ensure consistent, safe output regardless of database column naming.

Testing

• Added 5 new unit tests verifying:
  • Column names with shell metacharacters are sanitized
  • Column names with brackets/special chars are sanitized
  • Enum type names with special characters are sanitized
  • Fallback names are generated for all-special-character column names
  • Property keys are emitted as string literals
• Updated 16 existing snapshots to reflect the new quoted property key format
• All 100 tests in the package pass

[svidgen]

E2E & PR Checks Results ✅

Both batches completed successfully:

E2E batch (amplify-category-api-e2e-workflow:fec71fde-851d-46f5-ad25-8c7e92db76f5): 195/196 passed

• Only persistent failure: cleanup_e2e_resources — this is a post-test infrastructure cleanup job, not an actual test. All 195 real test builds passed.
• CodeBuild batch

PR checks batch (amplify-category-api-pr-workflow:fff7e3bd-b94c-4947-9ce9-18e35d6b16bd): 11/11 passed ✅

• CodeBuild batch

Ready for merge.

[Simone319]

Even though unlikely, if multiple fields contain no letter, and no number, they will result in the same name field. Shall we add a randomized suffix?

[svidgen]

I think that equates to a bad state. Randomization doesn't give an anchor point to code against.

[Simone319]

Fair point — randomization is the wrong call; a non-deterministic name would churn on every regen and give consumers nothing stable to code against. Withdrawing that suggestion.

That said, the underlying collision is still real: two all-special-character columns (e.g. () and @#$) both collapse to field, producing duplicate property keys. Since a column with zero alphanumeric characters is arguably a bad-state input anyway, a good follow-up would be to error with a clear message (pointing the user at an explicit rename/@mapsTo) rather than silently coercing. Fine to leave that for a separate change — flagging it so we don't lose the thread.