Artifact download: let HTTP do the rest

Start by reading the endpoint proposal in #262, the encoding issue in #283, and the artifact-format material discussed here. Work through the HTTP negotiation, signature-link, checksum, and artifact representation changes; done means the specification consistently defines one revision download endpoint plus its latest alias without the duplicated transport fields.

The download endpoint from #262 is a great move. /artifact/{uuid}/{artifactVersion}/download is something you can curl: no TEA client library, no metadata parsing, and content negotiation, ETag, Cache-Control and Repr-Digest all come from HTTP for free. Thanks for that.

I think it can be taken one step further. Once the endpoint exists, most of what artifact-format describes is already expressed by HTTP:

1. Format selection is Accept. The mediaType query parameter duplicates it, with its own matching and encoding rules (see #283). Dropping the parameter leaves what every framework already implements: Accept in, Content-Type and Vary: Accept out, 406 when nothing matches.
2. artifact-format reduces to a list of media types. With negotiation on the endpoint, an artifact needs at most to advertise which media types it is available in. The per-format sub-object with url, signatureUrl, checksums and description is no longer needed.
3. Direct download URLs are not needed. The endpoint already answers 302 to an external location. That covers pre-signed object storage, Maven Central and everything else url was for, and the token boundary is simply "under the API base or not".
4. The signature is a link on the response. An RFC 8288 Link header with a TEA relation type, for example Link: <…>; rel="https://tc54.org/tea/rel/signature", names the signature of exactly the representation returned, on GET and HEAD. There is no registered relation for detached signatures (the closest precedent in the IANA registry is c2pa-manifest), and RFC 8288 allows a URI, so nothing needs registering. No signature endpoint family, no mediaType parameter on it, no SIGNATURE_NOT_FOUND: no link means no signature.
5. Checksums are already there. Repr-Digest (RFC 9530) is defined on the download response. It can be the only place checksums live, and it covers HEAD too.

The result is one endpoint per artifact revision, plus its latest alias, and an artifact object that lists media types instead of describing transports. Everything else is standard HTTP that clients and servers already have.

References: #246 (motivation), #262 (the endpoint), #283 (encoding issue caused by the mediaType parameter).