feat: vendor the remaining 226 AWS models and answer the routing they contest

[skyoo2003]

Summary

Vendors the 226 AWS Smithy models DevCloud did not carry and regenerates internal/generated from the full set of 420, then resolves the only side effect that reaches runtime: 10 newly contested aliases and 2 that repointed without ever being reported as contested. No service is registered and every published coverage figure is unchanged.

Related Issue

Fixes #

Changes

• Vendored 226 models (smithy-models/ 194 -> 420), downloaded from aws/aws-sdk-go-v2 with the existing scripts/download-smithy-models.sh. 226/226 succeeded.
• Regenerated internal/generated from the full set: 224 new service packages (199 -> 423 entries), the alias table 432 -> 927, and roughly 5,687 more classifiable operations in the CRUD registry. make codegen is byte-for-byte idempotent.
• Answered 10 new contested aliases in serviceIDOverrides. Four of them route today and would have stopped: events, awsevents, ds, execute-api keep the target they already had. cassandra, mgh, wisdomservice are decided even though their target is not registered yet. sms-voice, aws-marketplace, partnercentral have no basis to pick and are recorded as deliberately unrouted.
• Pinned two silent repoints. sso and cloudhsm now have in-tree models that name themselves, so selfNamedClaimant hands each the alias with no collision raised. Both are pinned back to their prior answer, and cloudhsm gains the golden-alias pin it never had — without it that repoint failed no test at all.
• Updated the fleet-wide collision pin in internal/codegen/gen_aliases_test.go from 10 to 20, each entry commented with its claimants.

Deliberately not in this PR

No service registration, no hand-written providers, no docs/coverage.md edit. internal/generated/fidelity/, compat/services.json and cmd/devcloud/imports.go are byte-identical, because BuildFidelityData iterates providers rather than models — which is what makes this phase separable from provider registration.

Follow-up this PR creates

The sso and cloudhsm overrides are deliberately temporary. Delete both when internal/services/{sso,cloudhsm} exist; leaving them would route each service's traffic to the neighbour that used to stand in for it.

Files Changed

Area	Change
smithy-models/*.json	Added — 226 files
internal/generated/{service}/	Added — 224 packages
internal/generated/aliases/aliases_gen.go	Modified — 432 -> 927 aliases, 10 -> 20 collisions
internal/generated/crudregistry/registry_gen.go	Modified — +~5,687 operations
internal/gateway/protocol.go	Modified — 10 Group 1 entries, 2 Group 3 entries, Group 3 comment rewritten
internal/gateway/aliases_test.go	Modified — cloudhsm golden pin
internal/codegen/gen_aliases_test.go	Modified — collision pin 10 -> 20
changes/unreleased/Added-20260913-120000.yaml	Added — changelog fragment

Test Plan

• CGO_ENABLED=0 go build ./... and go vet ./... — clean
• CGO_ENABLED=0 go test ./... — green, with docs/coverage.md untouched
• golangci-lint run — 0 issues.
• rm -rf internal/generated && make codegen twice — byte-identical output, so codegen-drift has nothing to report
• make stats — still Services: 205
• Alias regression diff, the check no test performs: comparing the old and new ServiceIDs tables, LOST is exactly awsevents, ds, events, execute-api and REPOINTED is exactly cloudhsm and sso. All six are covered by an override in this PR; nothing else moved.
• The cloudhsm pin was verified by removing what it guards. With the override deleted, TestNormalizeServiceIDPreservesEveryKnownAlias fails with normalizeServiceID("cloudhsm") = "cloudhsm", want "cloudhsmv2". Before this PR that deletion would have failed no test in the tree.
• Claimant counts in every new comment were verified by recomputing BuildAliases's claim logic over all 420 models from the service shape traits, not taken on trust.

Checklist

• Self-reviewed the code
• Added/updated tests
• Lint/format passes (golangci-lint run)
• Updated documentation (if applicable) — N/A, the published figures do not move
• Added a Changie changelog fragment for user-facing changes

Note for the reviewer

The diff is large but splits cleanly: c12f4d5 is the vendored models and generated output, 8331ca1 is the ~40 hand-written lines. Only the second needs reading.

smithy-models/sso-oidc.json trips GitHub push protection on an upstream documentation example — the examples trait for the JWT Bearer grant, shipped by AWS in the public model with a dummy 123456789012 account ID. It was allowlisted as a false positive. Six models already vendored (s3.json, ecr.json, qapps.json and others) carry the same class of sample value.