chore: regenerate models from upstream schemas

[stack72]

Summary

Automated regeneration of extension models from upstream provider schemas.

Changes

• aws: 16 files changed
• gcp: 27 files changed
• digitalocean: 2 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.

Summary

All 61 changed files are under model/ (auto-generated — skipped per review policy). No changes to codegen/, vault/, datastore/, scripts/, or any hand-written code.

This is a legitimate regeneration: upstream provider schemas changed (new AWS services bcmpricingcalculator, braket, s3files; updated resources in bedrock, ecs, fsx, lambda, observabilityadmin, and several GCP/DigitalOcean services), but the codegen pipeline code itself is unchanged. Running the existing pipeline against updated upstream schemas produces new model/ outputs without requiring codegen/ modifications — this is expected behavior and not hand-editing of generated code.

The new service directories follow correct generated structure (LICENSE.txt, README.md, deno.json, deno.lock, _lib/aws.ts, model files, manifest.yaml). Manifest version bumps and TypeScript content are consistent with automated output.