Registry override set

Nobody has claimed this yet.

## Parent

#17

## What to build

The develop-against-a-different-registry case, which is the reason this feature needs configuration at all. A chart frequently names a registry that only exists at deploy time, while the developer is pushing somewhere else entirely.

Declaring registries in settings **replaces** whatever the file names — it does not add to it. Replacement is deliberate: a union would keep firing errors from the unreachable production registry in exactly the scenario this exists to support. The reference is checked against every declared registry and counts as existing if any of them has it, so the developer does not need to know in advance which one they pushed to.

Because a checkmark can now mean "exists somewhere other than where this file says", the UI has to be honest about it in three places. The checkmark names the matching registry whenever it differs from the file's. Error messages say an override redirected the check — which matters most in the Problems panel, where the inline annotation that would otherwise convey it is stripped away. And a status bar indicator shows overrides are active, answering "why is this file green when I know that image was never pushed".

One setting, a plain array of hostnames: non-empty it is the override set, empty it falls back to the previous resolution behaviour. Object entries with enable flags were rejected in spec #17 — disabling is a comment-out in JSON. Per-image pattern routing was rejected as a different feature with a different mental model. User and workspace scopes are left to the editor's native settings merge; the extension takes no position on which a developer should use.

## Acceptance criteria

- [ ] With registries declared, the file's own registry is not queried
- [ ] A reference is verified if any declared registry has it
- [ ] The matching registry is reported, and the checkmark names it, because it differs from the file's
- [ ] A reference absent from every declared registry produces a diagnostic that names the override
- [ ] With the setting empty, resolution falls back to the previous behaviour unchanged
- [ ] The status bar indicates when overrides are active
- [ ] Fan-out and attribution tested through the registry package's entry point, asserting every URL the injected fetch received and which registry the verdict credits

## Blocked by

- #21 — Checkmark decoration and hover for image reference results
- #23 — Document registry and the Docker Hub fallback

Start at the registry package's entry point and trace the existing resolution behavior, then review the blocked checkmark and hover work in #21 and registry documentation in #23. Add coverage for fan-out and attribution, asserting every URL received by the injected fetch and which registry receives credit. Done means override, fallback, diagnostics, checkmark, and status-bar behavior all satisfy the acceptance criteria.

Written by the indexing model from the issue text.