npm returns stale metadata as a plain 200 after upstream 404 or 401/403 #499

With cache_metadata enabled, fetchMetadataFromUpstream in internal/handler/handler.go falls back to the cached copy on any upstream error. That includes a 404, where the package has been unpublished or removed, and a 401 or 403, where the configured credentials have stopped working. Both are definite answers from the registry, and serving the cached copy in their place keeps the 404 or auth failure from reaching the client.

ProxyCached sets Warning: 110 - "Response is Stale" on fallback responses, but npm metadata goes through cachedRewrite and serveRewrittenMetadata in internal/handler/rewrite_cache.go, which drop the stale flag and return a plain 200. The client receives the old version list in a response that looks identical to a fresh one.

The fix is to carry stale through the rewritten response and set the same Warning header, and to pass 404 and 401/403 responses through to the client. A maximum stale age would also help, since the fallback currently serves a cached copy of any age. Tests should cover timeout, 304, 404 and 401/403 separately.

Related: #486 (cache behaviour when the upstream changes), #495 (stored metadata on 304), #496 (npm packument formats)