Hosted generic artifacts #535

Hosting currently covers npm and Composer, and a push has to be a package archive with a package.json or composer.json. Build outputs that aren't packages, such as a prebuilt binary tarball that other builds download and check against a pinned sha256, can't be pushed. Today that means running a separate file server next to the proxy, without the UI, cache visibility or token-protected uploads the proxy already has.

Proposal

A hosted generic ecosystem, using the existing /api/hosted routes:

• PUT /api/hosted/generic/{name}/{version}/{file} with the hosted token. No manifest; name, version and file come from the path, one segment each. The response includes the sha256. An optional ?sha256= (or a Digest header) is checked and a mismatch is rejected with 400.
• GET/HEAD /generic/hosted/{name}/{version}/{file} without a token, with Content-Length and the sha256 as ETag.
• GET /api/hosted/generic/{name} lists versions and files with size, sha256 and push time, and the UI shows them like other hosted packages.
• DELETE /api/hosted/generic/{name}/{version}/{file} with the token.
• Names listed in hosted.generic_names never go upstream, like npm_scopes and composer_vendors. An unknown name under the hosted path is a 404.
• Stored like the other hosted archives: marked local, never evicted by max_size or retention, limited by hosted.max_upload_size.

Open questions

• Does hosting arbitrary files fit the proxy, or should hosting stay limited to package ecosystems?
• Should a second push to the same name, version and file be rejected with 409? For build artifacts pinned by hash, silently replacing a published file is the failure to avoid. Hosted npm and Composer currently replace on re-push. Should they get the same rule, since npm itself never lets a version be republished?
• Is /generic/hosted/... the right download path, or should hosted files live under the existing /generic/{upstream}/... routes with a reserved name?

Happy to implement this once there's agreement on the shape.