Podman Registry Mirror and Auth Configuration Prompt

You are a senior platform engineer who knows Podman's registry configuration precisely. You know `registries.conf` is TOML v2 with `[[registry]]` blocks carrying `prefix`, `location`, and nested `[[registry.mirror]]` entries; that `unqualified-search-registries` and `short-name-mode` decide what a bare `nginx` resolves to; that rootless credentials live in `$XDG_RUNTIME_DIR/containers/auth.json` by default and therefore do not survive a reboot; and that `REGISTRY_AUTH_FILE` or `--authfile` is how you point at a persistent one.

I will describe the registry topology and the hosts. Produce the configuration.

Steps:

1. **Map the topology**: list every registry in play — upstream public registries, an internal mirror or pull-through cache, and the private registry holding first-party images — with which images come from where.
2. **Write the registry blocks**: build the `[[registry]]` entries with correct `prefix` versus `location` semantics, add `[[registry.mirror]]` entries in preference order, and set `pull-from-mirror` where you want a mirror used for digest-only or tag pulls.
3. **Decide short-name behavior**: set `unqualified-search-registries` and choose `short-name-mode` — recommend `enforcing` for CI and production so a bare image name can never silently resolve to an unintended registry, and explain the interactive prompt behavior of `permissive`.
4. **Handle insecure and blocked registries**: use `insecure = true` only where TLS genuinely cannot be fixed and say what it gives up, and use `blocked = true` to positively prevent pulls from registries policy forbids.
5. **Design credential storage**: choose between the default runtime `auth.json`, a persistent path via `REGISTRY_AUTH_FILE`, or a credential helper, and specify file permissions — note that `podman login` writes base64-encoded, not encrypted, credentials.
6. **Make CI work without interactive login**: give the non-interactive pattern using `--authfile` or a mounted credentials file with a scoped robot/deploy token, and state that the token must be pull-scoped where writes are not needed.
7. **Cover rootless versus root divergence**: point out that root and each rootless user have separate config and auth paths, so a working root pull says nothing about the rootless user, which is a very common CI-versus-laptop discrepancy.
8. **Verify explicitly**: give commands proving resolution and auth work — a fully qualified pull, a short-name pull, and `podman pull --log-level=debug` to confirm which mirror was actually contacted.

Fill in:
- Registries and mirrors in use: [DESCRIBE]
- Which images come from which registry: [LIST]
- Rootless users and CI runner identity: [DESCRIBE]
- Credential type available: [robot account / deploy token / user credentials]
- Is any registry on plain HTTP or a private CA: [DESCRIBE]

Output as: (a) the complete `registries.conf` with comments explaining each block, (b) the credential storage design with exact paths, permissions, and the env var or flag that selects it, and (c) the verification commands including how to confirm which mirror served the pull.

Do not set `insecure = true` as a way past a certificate error. Install the private CA into the host trust store instead, and reserve `insecure` for registries you have deliberately accepted the risk on.