docs(testing): add the maven remote e2e scenario catalog

Why

maven is the only format with no remote scenarios. npm has 25, oci 16, docker 5.

The catalog's scope line explains it:

Out of scope until the capability ships: Virtual and remote (proxy/cache) Maven repositories — owned by S30 and S14.

That has gone stale. S14 is Status: Approved, and the management API accepts a maven remote from kind=remote plus settings.url on .com — I created one and deleted it while checking:

maven  -> 201     npm    -> 201
docker -> 201     oci    -> 201

What this adds

29 rows in a new ## Remote repositories section, derived from S14's 54 acceptance criteria, and the scope carve-out narrowed to virtual only — worded the way the npm catalog words its own.

Group	Rows
Artifact proxy	8
Metadata proxy	5
Sidecar synthesis	4
Error mapping	5
Credentials, health, eviction	6
End-to-end resolve	1

18 are automatable today. 11 are blocked.

Three contracts that get their own rows

Each is somewhere a reader would otherwise carry an assumption over from the hosted rows or from npm, and be wrong:

• Sidecars are synthesized, never proxied. Checksums come from the cached parent's digest columns, and no request ever targets an upstream .sha1, .md5, .sha256 or .sha512 URL. An upstream that serves no sidecars still yields verifiable checksums. S14 spends 10 of its 54 criteria here and npm has no equivalent, so it is its own group.
• Maven Central is pinned. A remote for repo1.maven.org or repo.maven.apache.org defaults cache_validity_hours to 0 and never revalidates. Every freshness scenario therefore needs a non-Central upstream or an explicit override, and metadata_cache_validity_hours is a separate window rejected at 0.
• Cold fills differ by kind. An artifact cold fill streams to the client while the cache fills, so its 200 carries no ETag. A metadata cold fill commits first and carries the full header set. One rule for both produces the wrong assertion.

One row is maven-only for a reason worth keeping visible: remote.upstream-user-agent. S14 notes Maven Central answers 429 to the Go client default, so identifying the registry gates usability against Central rather than being cosmetic.

What the blocked rows need

An instrumented upstream — one whose request count, response codes, and content the test controls, reachable from the registry. A public upstream cannot be made to fail, to change a file, or to report how many times it was asked, and those are exactly the assertions behind single-flight, revalidation, the freshness windows, and the error mapping.

That one dependency also blocks rows already in the npm and oci catalogs, so it is worth solving once rather than per format.

Two rows need more than that: sidecar-md5-under-fips needs the service running FIPS-on, and artifact-snapshot-revalidates needs an upstream serving snapshots, which Central does not.

What this does not do

• No docker rows. The docker catalog states that its remote rows assert the CLI journey while the per-response assertions live in the oci catalog, since both formats share /v2/ and the container_* tables. Adding docker rows would duplicate oci's 16.
• No status flipped to implemented. Nothing in the harness covers these yet.

One thing spotted next door

The npm catalog's remote section still says a remote repository cannot be created through the management API and that the binding is seeded out of band. The probe above shows npm returning 201 the same as maven, so that intro looks stale too. Not touched here.

🤖 Generated with Claude Code