feat: resolve tagless images through the governing chart's appVersion

[CptSchnitz]

Tagless image references start getting answers. An image: block with a repository and no tag is now checked against the appVersion of the chart that governs the file, matching what Helm itself would render, where before it produced a muted question mark and nothing else. File scope widens with it: any YAML file beneath a chart directory is checked, so environment overlays like production.yaml get the same scrutiny as values.yaml, and anything under that chart's templates/ is skipped because Go template source renders to nothing checkable.

The governing chart is the one in the nearest ancestor directory holding Chart.yaml. That single rule is what makes a subchart's values file resolve against the subchart's own appVersion rather than its parent's, which is the version actually deployed. One walk up the tree answers scope, the templates exclusion, and tag resolution together, rather than three rules that could disagree.

A tag the file never wrote needs different handling on every surface, so the resolved tag is a discriminated union. A file tag carries a range to underline. A chart-metadata tag carries the metadata path instead, so its diagnostic attaches to the repository value and its message names the chart. Surfaces cannot forget the distinction, because there is no range on that arm to reach for. Saving a Chart.yaml re-checks the open files that chart governs, since a version bump is exactly when a stale checkmark costs the most.

Chart context lives in the Helm package with the filesystem read injected, per the decision recorded in #17: which chart governs which values file is Helm knowledge, and leaving it in an editor extension guarantees a future CLI reimplements it. The module holds no platform path semantics and splits URI paths itself.

no-tag is gone. The ticket requires silence when there is no chart metadata or no appVersion, so those references are dropped before any registry is asked, which made the reason dead. Its ReferenceVerdict and UncheckedReason aliases went with it in the same wave rather than surviving as shims, and the five consumers now use ImageVerdict and UnverifiableReason from the registry package directly.

Reviewer notes

• Read the five commits in order. The first is a pure extraction of raw scalar reading so chart metadata can reuse it, and it leaves the existing extractor tests untouched. appVersion goes through the same path as tags for the same reason: YAML coerces appVersion: 1.10 to the float 1.1, and a chart whose appVersion is templated is no more usable than one with none.
• The last two commits are review fallout and carry the only behaviour changes worth a second look. Chart.yml was accepted alongside Chart.yaml and should not have been, since Helm's own loader recognises only Chart.yaml, so accepting it would resolve an appVersion out of a file Helm ignores. Dropping it also halves the filesystem probes per directory level and lets the watcher glob be derived from the resolver's constant instead of spelled out again in another workspace.
• A chart's own Chart.yaml came back in scope as a values file, because the exclusion only tested for a templates segment. Harmless in practice, since dependencies[].repository entries carry no corroborating sibling key, but it is fixed rather than left to chance.
• The watcher's onDidCreate registration was deleted because it could match nothing. A document checked without a chart records no metadata path, so a Chart.yaml appearing above it would never re-check it. Catching that means re-resolving every open document on every write, which no ticket has asked for, and the limitation is documented on the handler.

Known gaps

• The ancestor walk is unmemoised, costing up to one read per directory level on every open and on every chart metadata change. Real but out of scope here, and Persistent result cache and request concurrency cap #27 is where request cost gets addressed.
• vscode.Uri.file pins the reader's scheme to file, so a virtual workspace resolves no charts and falls back to the values-file naming rule. Noted in the reader's own docstring.

Closes #24

🤖 Generated with Claude Code