Investigate: registry.jujucharms.com images not served by docker-registry cache

**Note: This issue was generated with AI assistance (GitHub Copilot) based on automated log analysis and triage.**
Filed by @canonical/solutions-qa

## Summary

During a `content-cache-k8s` test run, the `neighbor` (discourse-k8s) pod got stuck in `PodInitializing` for the full 15-minute deploy timeout because its OCI image (`registry.jujucharms.com/charm/1do4bht9nkx2kuk2thi94lw9kzlgiytu42u4r/discourse-image`) could not be pulled in time on a cold node.

The docker-registry pull-through cache (`10.131.231.165:5000`) does not appear to serve images from `registry.jujucharms.com`, meaning cold nodes must pull large charm OCI images directly from Charmhub on every first deployment.

## Test Observer Link

https://test-observer.canonical.com/#/charms/406365?testExecutionId=458265&testResultId=10360190

## What to Investigate

- Should `registry.jujucharms.com` go through a docker-registry pull-through cache?
- Is this a configuration issue or a fundamental incompatibility (e.g. Charmhub auth)?

## Impact

Any test run that lands on a cold node (one that has never deployed a given charm's OCI image) risks timing out during deployment.

Start with the content-cache-k8s test run and the docker-registry pull-through cache at 10.131.231.165:5000. Investigate whether registry.jujucharms.com images can be served through the cache or whether Charmhub authentication prevents it; done means establishing the cause and confirming that cold-node charm deployment no longer times out.

Written by the indexing model from the issue text.