P1: Keep private repository downloads and pages out of shared caches

Why

The instance explicitly marks artifact, archive, and run-artifact downloads Cache-Control: public, max-age=300 (server/web/releases.go and server/web/runs.go). Those handlers resolve the repository through w.open, so a private repository answers 404 to an anonymous reader. A shared cache in front of the instance can still store the response an authorized user received and serve it to the next reader without asking the origin. The deployment guide only asks for a TLS proxy; it does not say that a caching proxy or CDN must not cache private content.

Dynamic HTML has a weaker version of the same exposure. Web.render sets only Content-Type; only the auth/account pages and run logs set no-store. A shared cache may cache an authorized issue or change page by URL and serve it to an anonymous reader.

Scope

• Pass the repository’s visibility into the download handlers: set public only when anonymous read is allowed (the same question w.open answers for an anonymous request), otherwise private/no-store.
• Set a safe default for dynamic HTML (Cache-Control: private, no-cache or equivalent) in render or the middleware, keeping no-store for auth and account pages.
• Check ReleaseArtifact, ReleaseTar/ReleaseTarGz, RunArtifact, raw file responses, and the admin pages.
• Add tests: a private repository’s artifact and archive responses do not carry a public directive; an authorized private page is not publicly cacheable.

Acceptance

• No private repository response carries a public cache directive.
• Dynamic authenticated pages are private or no-store.
• A shared cache in front of a test instance cannot serve a private artifact or page to an anonymous client.
• The deployment guide says whether a cache is supported, and if so what it may cache.

From the internal review for #106.