fix: eight query providers fabricated a success for unimplemented actions

[skyoo2003]

Summary

Eight query-protocol providers answered any operation they do not implement with HTTP 200 and an empty <ActionResponse/> — a fabricated success, which docs/coverage.md calls the one thing DevCloud must never do. The body also carried no <ActionResult> wrapper, so botocore's query parser raised KeyError instead of returning a value: neptune.describe_db_cluster_endpoints() crashed the SDK outright.

Follows up #144, now merged. Base is main.

Related Issue

N/A — follows up finding 1 recorded in #144's "Findings recorded, deliberately not fixed here".

Changes

The fix — eight default branches now return nil, plugin.ErrUnhandledOp, which is what every other provider in the fleet does and what the CRUD engine has been reachable through since #143.

rds · neptune · docdb · redshift · elasticache · autoscaling · cloudformation · elasticloadbalancingv2

Root cause, not the reported symptom. The report was one operation on neptune. neptune and docdb sign as rds, so their probes never reach their own providers and neither appeared in the failing list — but both carry the identical branch. All eight are fixed; leaving two would leave the bug in place for anyone reaching them directly.

The reproducer — tests/compatibility/test_no_fabricated_success.py asks every registered service for one operation the fidelity manifest does not list as served, and fails if the answer is a success. It was written fleet-wide rather than against the eight services found by reading the code, and that paid for itself: it found two more (resourcegroups.Tag, s3.ListBucketAnalyticsConfigurations).

test_service_smoke.py already asserted this guarantee for services that serve nothing. The gap was the other case — a service that serves plenty and answers an operation it does not implement with an empty success anyway.

Published figures move, and had to. 223 operations go from unimplemented to auto-crud: they are served from the real store now instead of being fabricated. docs/coverage.md's tier table moves with them — auto-crud 4,970 → 5,193, unimplemented 2,941 → 2,718, total unchanged at 12,407.

That edit was not optional. #144's gate failed until the published numbers matched the manifest, naming both:

coverage_test.go:162: docs/coverage.md publishes 4970 auto-crud operations, the manifest holds 5193
coverage_test.go:162: docs/coverage.md publishes 2941 unimplemented operations, the manifest holds 2718

This is the first time that gate has caught a real change rather than a deliberate mutation.

Test Plan

RED (commit c65b9d9, output quoted in its message):

FAILED [autoscaling.DescribeAdjustmentTypes]        FAILED [rds.DescribeBlueGreenDeployments]
FAILED [cloudformation.DescribeChangeSetHooks]      FAILED [redshift.DescribeAccountAttributes]
FAILED [elasticache.DescribeCacheEngineVersions]    FAILED [resourcegroups.Tag]
FAILED [elasticloadbalancingv2.DescribeCapacityReservation]  FAILED [s3.ListBucketAnalyticsConfigurations]
8 failed, 120 passed, 17 skipped

GREEN (commit 34ee0b0): 126 passed, 17 skipped, 2 xfailed

CGO_ENABLED=0 go test ./...                             → all pass
make codegen; git status --porcelain internal/generated → clean
golangci-lint run                                       → 0 issues
pytest tests/compatibility/                             → 1119 passed, 17 skipped, 2 xfailed in 13.28s

What is deliberately not fixed

Two of the eight failures are a different mechanism and are marked xfail(strict=True) — so they fail the moment they start passing, rather than rotting into an accepted state.

Case	Observed
s3.ListBucketAnalyticsConfigurations	GET /{Bucket}?analytics answers 200 with an empty body. S3's provider default returns MethodNotAllowed, so it is not that branch
resourcegroups.Tag	PUT /resources/{Arn}/tags answers 200 echoing the request's Arn and Tags

The recorded reasons state only what was observed. An early hypothesis — that httproute.Match ignores the HTTP method, letting PUT /resources/{Arn}/tags be served by the registered GetTags at the same path — was checked and is wrong: match.go:42 compares methods. Rather than commit a confident wrong cause, the comment says the mechanism is unidentified.

Also unchanged from #144's findings: the four unreachable Lex services (needs a four-way path split) and the three operations labelled hand-verified that no route reaches.

Checklist

• Self-reviewed the code
• Added/updated tests
• Lint/format passes (golangci-lint run → 0 issues)
• Updated documentation (docs/coverage.md tier table)
• Added a Changie changelog fragment for user-facing changes (Fixed)