docs: stop the per-service pages promising the opposite of what the code does

[skyoo2003]

Summary

The five per-service pages under docs/services/ were last touched on 2026-04-18. Four of them describe a DevCloud that no longer exists, and they fail in the direction that costs a reader the most: their Known Limitations lists deny features that are now implemented. Someone reads "No batch operations" and writes the workaround for a BatchWriteItem that has worked for months.

Operation tables are now derived from internal/generated/fidelity — the hand-verified tier per service, the same source the coverage gates read — rather than from memory.

Changes

Operation tables re-derived

Page	Documented	Hand-verified	Wrongly listed as absent
s3.md	8	37	Multipart upload, CORS, bucket policy, ACL, versioning, tagging, ListObjectsV2, CopyObject, DeleteObjects, HeadBucket
dynamodb.md	8	20	UpdateItem, batch, transactions, GSI/LSI, streams, TTL, conditional writes, filter/projection expressions
lambda.md	6	25	Versions, aliases, event source mappings, resource-based policies
iam-sts.md	6 (IAM)	58 (IAM) + 4 (STS)	Groups, inline policies, instance profiles, tagging, the delete/update half of the user and role lifecycle; STS was missing GetAccessKeyInfo

sqs.md was already current and is untouched.

Limitations rewritten around what is actually load-bearing

The same shape recurs in three services: a sub-resource round-trips faithfully and changes nothing. S3 stores a versioning status without assigning version IDs, stores ACLs and bucket policies without ever denying a request, and stores CORS without emitting an Access-Control-* header. Lambda accepts a resource-based policy it never evaluates. IAM stores policy documents nothing parses. Each is now stated as stored, not evaluated at the operation that stores it — a green response is exactly what makes it dangerous.

Lambda's headline limitation survives unchanged because it is still true: Invoke returns a fixed placeholder and the handler never runs. It is now stated with the response body, since nothing in the shape of that reply distinguishes it from a real one and a test asserting on the status code alone passes against code that did not execute. The event source mapping rows say what they really do — the SQS and DynamoDB stream pollers run, build the AWS-shaped event, and POST it to that stub.

Two storage-layer claims were wrong

• DynamoDB is SQLite, not BadgerDB. internal/storage/ contains only sqlite/, and badger appears in neither go.mod nor go.sum. README.md, docs/configuration.md and docs/contributing.md were pointing new service authors at a dependency the tree does not have.
• docs/configuration.md documented three config keys that do not exist — services.lambda.runtime, services.lambda.warm_containers, services.iam.enforce_policies. config.ServiceConfig has exactly two fields, and parse() uses a non-strict yaml.Unmarshal, so writing one of those is dropped in silence. That is the failure mode config.go already grew a warning for on auth.enabled; this stops advertising the keys and says plainly that a knob outside the table does nothing.

Files Changed

File	Change
docs/services/s3.md	Modified — operation table, notification behaviour, limitations
docs/services/dynamodb.md	Modified — backend, attribute types, operation table, limitations
docs/services/lambda.md	Modified — operation table, event source mapping behaviour, limitations
docs/services/iam-sts.md	Modified — IAM/STS operation tables, limitations
docs/configuration.md	Modified — removed three phantom config keys, corrected DynamoDB backend
docs/contributing.md	Modified — storage backend guidance for new services
README.md	Modified — DynamoDB backend

Testing

• go test ./cmd/devcloud/ — green. The published-figure gates were re-run: 431/426, the fidelity shares and the 1,530-test suite each re-derived and already agreed with the binary, so no gated number was touched.
• make docs-build — green. 903 internal links across 24 pages all resolve.
• Every claim written here was checked against the source it describes rather than against the previous page: the fidelity manifest for operation tiers, each provider's HandleRequest dispatch for behaviour, config.ServiceConfig for config keys, and internal/storage/ plus go.mod for backends.

Related Issues

None.