chore: regenerate models from upstream schemas

[stack72]

Summary

Automated regeneration of extension models from upstream provider schemas.

Changes

• aws: 13 files changed
• gcp: 36 files changed

Schema Sources

• AWS: CloudFormation Resource Schema
• GCP: Google Discovery Documents
• Hetzner: Hetzner Cloud OpenAPI spec
• DigitalOcean: DigitalOcean OpenAPI spec

Review Notes

• Files under model/ are auto-generated — review the manifest.yaml diffs for version changes
• CalVer versioning with content-based change detection ensures versions only bump when content changes
• Publishing happens automatically when this PR is merged (via the publish workflow)

[github-actions]

Code Review

Blocking Issues

1. Model files changed without corresponding codegen/ changes. This PR modifies .ts model files under model/aws/ and model/gcp/ (e.g. cloudfront/extensions/models/distribution.ts, route53resolver/extensions/models/resolver_endpoint.ts, sqladmin/extensions/models/instances.ts, and 30+ others) with content changes beyond version/upgrade entries — new fields, enum additions, deprecation removals, descriptor updates. However, no files under codegen/ are changed.

   Per the review policy, model files may change without codegen changes only in two legitimate cases:

   • Codegen regeneration (codegen/ must also change)
   • Version bumps via bump-versions script (only version, upgrades, and manifest entries change)

   Neither case applies here: the changes span .ts files (not just manifests), and codegen/ is untouched. This matches the blocking pattern: hand-edited generated code.

   If this is a genuine schema-driven regeneration, please include the codegen run evidence — either commit the updated codegen/ artifacts, or confirm via CI output that the pipeline was executed and these .ts files are its exact output (and that running the pipeline a second time produces no further diff).

Suggestions

• None.