chore: regenerate models from upstream schemas

[stack72]

Summary

Automated regeneration of extension models from upstream provider schemas.

Changes

• aws: 6 files changed
• gcp: 22 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

None.

Observations

All 28 changed files are auto-generated files under model/ with proper auto-generation headers. This is a legitimate automated regeneration from upstream provider schema changes (AWS CloudFormation + GCP Discovery Documents). No codegen/ pipeline changes are expected since only upstream schemas changed, not the pipeline itself.

Changes verified:

• AWS: appintegrations/application — Description made optional, new ApplicationType enum field added; connectcampaignsv2/campaign — new EntryLimitsConfig added; lambda/function — EFS ARN regex extended to support S3 file system ARNs
• GCP: agentregistry/bindings — new model file added following standard generated pattern; bigquerydatapolicy/datapolicies — new dataGovernanceTag field; dataflow/jobs — new latencyTier field, deprecation notices updated; drive/files and changes — new clientEncryptionDetails field + new generate_cse_token method; firestore — removed upstream-dropped fields (customPartitionFieldPaths, numberSpec); ondemandscanning — removed upstream-dropped aiSkillAnalysis field; various description-only updates for servicemanagement, hypercomputecluster, developerconnect

All new fields are optional, so no breaking data migration is needed — upgrade entries correctly use passthrough upgradeAttributes.

Suggestions

• Some upgrade entry descriptions say "No schema changes" (e.g., dataflow/jobs adding latencyTier, developerconnect adding httpProxyBaseUri) when structural schema changes did occur. The phrasing is accurate in the migration sense (no upgradeAttributes logic needed), but could be more precise (e.g., "Added optional field: latencyTier") for changelog clarity. Minor — doesn't block merge.