Proxy cache project transitions from global pull-through to project-scoped upstream auth in Harbor

Goal is to understand cache freshness and credential isolation when using the project-scoped proxy cache instead of the legacy per-registry pull-through cache.

The feature binds upstream registry credentials to a dedicated proxy-cache project rather than using global configuration, which changes multi-tenant isolation. Cached manifests and blobs are served from Harbor without contacting upstream unless the entry is evicted or explicitly purged. Garbage collection interacts with proxy-cache artifacts, so storage reclamation is delayed until GC runs. Behavior around upstream token authentication and default cache headers may vary across Harbor 2.x minor releases.

The unresolved decision is whether to accept potentially stale content until manual purge or implement an external eviction policy, and how to measure impact before optimization.

Questions:

• What is the documented revalidation behavior for cached manifests in a proxy-cache project?
• Does upstream tag deletion affect subsequent pulls from Harbor without manual purge or GC?
• How does project-scoped credential isolation interact with upstream token auth compatibility boundaries?