Tags API (2017-03-31 family)

[lex00]

The three tagging operations on the classic Lambda tags routes at /2017-03-31/tags/{Resource} — a third path prefix on the same listener, belonging to neither MicroVM URI family. Resource is a whole ARN in one path segment, which works because every taggable MicroVM-family ARN is colon-separated with no slash in it. Based on main.

Coverage is now complete

pass 71, fail 0, unimplemented 0, skipped 0, error 0
coverage: 29/29 operations exercised

/_m80/health reports 29/29 implemented with an empty pending list. Every operation in the inventory now has both an implementation and a fixture-backed case behind it — the first time the suite has run with nothing skipped and nothing unimplemented.

Where tags live

Not in this package. A tag set belongs to the thing it is on: an image's tags have to appear in the image's own responses, and a copy kept centrally would be a second truth that drifts the first time anything reads the wrong one. tags declares a Resource interface, routes an ARN to whichever package owns it, and does nothing else. images.Image already had a dormant Tags field, initialised empty at create and never written — this is what it was waiting for.

VM and connector ARNs are taggable too, per the issue's task list, and store tags that never reach the wire. No recorded response for either carries a tags member, and inventing one to show them would be a divergence on every read.

Recorded, and one thing worth a second look

Both mutations answer 204 with an empty body. The fixtures for those two steps are zero-byte files — which is what no content looks like on disk, and is easy to mistake for a failed recording. ListTags answers 200 with a Tags map, and an untagged resource gets an empty object rather than null.

Two behaviors are not recorded and I chose them deliberately: tagging merges rather than replaces (it adds and overwrites the keys it names, leaves the rest alone — which is what untag exists for), and untag is idempotent (removing an absent key is not an error). Both are how the classic Lambda tags API behaves, and the alternative in each case would make a reconciler converging on a desired tag set fail to converge — the same non-converging-loop failure mode docs/floci.md flags as the one that actually matters.

TagKeys rides the query string as tagKeys; the SDK repeats the parameter and m80 also accepts it comma-separated, since a human with curl will write it that way and neither costs anything.

go build, go vet, gofmt, go test -race clean.

Closes #14