test(e2e): lower the rig body caps and assert the two size rows

One coordinated rig-values change lifts two blocked rows and needs no new profile — limitations.md had recorded them as needing mutually exclusive values, and the arithmetic does not bear that out.

server.max_body_size     "5MB" -> "512KB"   (SI: 5,000,000 -> 512,000)
maven.max_artifact_size  unset -> "4MB"
maven.max_metadata_size  unset -> "1MB"

Two Maven keys, not one: internal/config/maven.go:135 refuses max_metadata_size > max_artifact_size, which the limitations entry omitted.

OverGlobalBodyCap moves 6 << 20 -> 1 << 20, because the payload now sits in a band rather than merely exceeding one number — at 6 MiB the Maven over-cap row's deploy would be refused by the very cap its sibling row exists to reach. Both rig caps are now exported constants and both edges are pinned.

Also fixes a latent defect found on the way: riggedTarballCap read "512KB" as 512 * 1024. Verified at the boundary on a rig — a 518,797-byte tarball sits between the corrected 512,000 and the old 524,288, and the registry refuses it.

Blast radius, checked route by route. Every format upload route reads server.UploadBody and is unaffected. The OCI manifest PUT is the exception — it is bounded by the body middleware, so a manifest is now capped at 512,000 rather than container.manifest_max_payload's 4,000,000. Harmless for real manifests; no row or fixture exercises that cap.

Rig-verified: 4 of the 5 affected rows pass; the 5th is fixed by the second commit.

Deletes both lifted limitations.md entries, per that file's own rule.

Also corrects the emission entry's affected set in that same file (empty as it stands -> 87 of the 145 ids), deliberately rather than as a drive-by: the claim was false when written, not overtaken, and !2491 deletes that entry outright, so a split MR carrying the correction would be obsolete on arrival.

Related to #1289

🤖 Generated with Claude Code