chore: regenerate models from upstream schemas

[stack72]

Summary

Automated regeneration of extension models from upstream provider schemas.

Changes

• aws: 17 files changed
• gcp: 23 files changed
• digitalocean: 1 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 contain content changes beyond version/upgrade entries with no corresponding codegen/ changes.

   All 41 changed files are under model/ (auto-generated), yet codegen/ has zero changes. Per CLAUDE.md and the project's review policy, model files may change without codegen changes only in two legitimate cases:

   • Codegen regeneration — requires codegen/ to also change (pipeline or schema code modified)
   • Version-only bumps via bump-versions — only version, upgrades, and manifest entries change

   This PR's model changes go well beyond version/upgrade entries and include real content diffs:

   • New file: model/aws/elasticache/extensions/models/cache_cluster.ts (433 lines)
   • New fields: UseClientCertificateOCSPEndpoint (cloudfront/trust_store), DatabaseInstallationFiles (rds/custom_dbengine_version), defaultUriDisabled (gcp/run/instances), postgresHomogeneousConfig (gcp/datamigration/migrationjobs)
   • Removed method: update_memory_layer (~44 lines) from gcp/bigtableadmin/instances_clusters
   • Enum changes: passthrough added to cloudfront distribution mTLS mode; POSTGRES_19 and PROJECT_ABUSE added to sqladmin instances
   • Regex change: IAM role ARN pattern in model/aws/eks/addon.ts
   • Description wording changes across multiple dataproc, logging, datalineage, and accesscontextmanager models

   If this was produced by running the codegen pipeline against new upstream schemas, please include the corresponding codegen run evidence or ensure the CI automation commits any affected codegen/ artifacts (e.g. fetched schema snapshots, deno.lock updates inside codegen/) alongside the regenerated model output. Without that, these look like hand-edits to generated files.

Suggestions

1. The releaseNotes removal from manifests like bedrockagentcore, chime, datazone, deadline, firestore, interconnect, ondemandscanning, storagebatchoperations, and digitalocean (where no model .ts files changed) is correct behavior — removing stale notes from a prior run — but it's worth verifying the codegen pipeline intentionally clears releaseNotes when there are no content changes in a given cycle.

Autorelease of the models