feat: hand-write the eight services the CRUD engine cannot classify

[skyoo2003]

Summary

Eight AWS services hold no CRUD-shaped operation between them, so the generic engine can never classify their 31 operations and scaffolding would leave them registered and serving nothing. Each gets a hand-written provider, plus the one piece of plumbing without which three of them would be registered and reachable by nothing.

Related Issue

Refs #160 (Phase 1 — the models these eight are built from)

Changes

The eight providers — 31 operations, all hand-verified, none unimplemented

Service	Ops	Protocol	Note
eksauth	1	rest-json
inspectorscan	1	rest-json	echoes the SBOM — DevCloud runs no scanner
ec2instanceconnect	2	json-1.1
kinesisvideowebrtcstorage	2	rest-json	signs as kinesisvideo
marketplacecommerceanalytics	2	json-1.1
cloudsearchdomain	3	rest-json	signs as cloudsearch; sqlite-backed, documents round-trip
georoutes	5	rest-json	empty result sets — no road graph ships
paymentcryptographydata	15	rest-json	signs as payment-cryptography; encrypt→decrypt round-trips

crud.RegisterRoutes — why the contested three are reachable

The gateway splits a shared SigV4 signing name by asking each sibling whether it models the request. That question reads a route table built only from CRUD-classifiable operations, and these services have none — so payment-cryptography-data's traffic was kept by the control plane, and cloudsearch-domain's by a Query provider. RegisterRoutes lets a provider declare the routes it serves by hand. It claims nothing about fidelity: Handle still finds no OpMeta and returns ErrUnclassified. What it changes is which service is asked. Handle is untouched, and no serviceIDOverrides entry was added — the model decides, not a hardcoded winner.

Compatibility harness

_coverage.py's stub builder could not satisfy two of the eight client-side: a string minimum (SSHPublicKey is 80 characters at the least) and a tagged union with no member set. Both read as a service serving nothing when the defect is in the harness — the same way an unsatisfied collection minimum already did, which that file handles and comments on. Nothing in any assertion was weakened.

A pre-existing fabricated success, surfaced and recorded

Padding strings to their minimum made one probe reach the gateway for the first time, and it found workspacesweb.AssociateBrowserSettings answering 200 for an operation nothing implements: the CRUD registry holds only classifiable operations, so UpdatePortal at PUT /portals/{portalArn+} greedily swallows /portals/<arn>/browserSettings. The fix belongs in codegen and was implemented and measured before being reverted — it moves 569 operations between fidelity tiers and takes registered-only from 4 to 1. That is a coverage re-derivation of its own, so it is recorded in test_no_fabricated_success.py's own KNOWN_UNFIXED ledger as a strict xfail with the mechanism named, and left to the scaffolding phase.

Three wire-level defects found by driving real clients

Every unit test here asserts Go-side response maps, which is a layer above the wire. Pointing real boto3 clients at all 31 operations found three defects invisible to them — all fixed, each with a reproducer that was confirmed RED first:

• cloudsearchdomain.Search was unreachable. botocore rewrites it from the modelled GET /2013-01-01/search?format=sdk&pretty=true into a POST with those terms in a form body. The modelled route matched nothing, so the request stayed with cloudsearch and came back 501. The provider now declares the POST route — the same table backs its own resolution and RegisterRoutes, so the two cannot disagree — and reads q from the form body.
• GeneratePinData returned PinData: {}. It is a tagged union; botocore raises PinData must have one and only one member set rather than returning, so the 200 was unusable. It now carries the member the caller's generation attribute implies.
• geo-routes sent PricingBucket in the body. The model binds it to the x-amz-geo-pricing-bucket header, so botocore discarded it in all five operations without erroring. It is a header now.

Published figures, re-derived

Figure	Before	After
Registered	205	213
Serving ≥1 operation	201	209
Registered-only	4	4 (same four services)
Compatibility-tested	203	211
hand-verified	4,497	4,528
auto-crud / unimplemented	5,193 / 2,717	unchanged
total known	12,407	12,438

The "coverage target is 205 services" blockquote and the whole "The target" section are deliberately untouched — that is the structural rewrite a later phase owns. The target reading 205 next to 213 registered is correct and temporary.

Test Plan

• go vet ./... — clean
• golangci-lint run — 0 issues.
• CGO_ENABLED=0 go build ./... — clean
• CGO_ENABLED=0 go test ./... — green, including the five published-figure gates
• make test-compat — 1,155 passed, 1 xfailed (was 1,144 tests before this branch)
• make stats — Services: 213
• make codegen run twice, byte-identical
• make build — 34.8 MiB, budget 45 MiB
• Coverage of the eight packages + crud: 87–96%, all above the 80% floor
• All 31 operations driven through real boto3 clients against a running server: 31/31 correct

Two tests were proven to bite rather than trusted:

• Commenting out one crud.RegisterRoutes call makes TestContestedDataPlanesResolveToThemselves fail with expected: "paymentcryptographydata", actual: "paymentcryptography" — the control plane keeping the request, which is the exact failure the mechanism exists to prevent.
• Commenting out the POST /2013-01-01/search route makes the new test_handverified_is_reachable.py row fail with cloudsearchdomain.Search … answered 501.

Both files were restored byte-identical and re-verified green.

Checklist

• Self-reviewed the code
• Added/updated tests
• Lint/format passes (golangci-lint run)
• Updated documentation (if applicable)
• Added a Changie changelog fragment for user-facing changes