feat(podspec): find images at configured per-kind JMESPath expressions (option D)

[MPV]

Option D of the candidates for #26, raised side by side so they can be compared. Scope feat(podspec) finds the set — #81 #82 #83 #84 #106. Only one should be merged.

See also #106, which combines this PR with #82 — these expressions for what inference cannot see, structural inference for everything else. It keeps this PR's reach while removing the need to configure resources whose shape already speaks for itself.

Rebased onto 2abd515 (0.4.3) — Kubernetes v0.36.3, Go 1.26.

	master	A · reflection	B · structural	C · CUE	D · config ← this	E · B+D
CR embedding a PodSpec (Argo Rollout)	✗	✗	✓ auto	✓ auto	✓ via config	✓ auto
CR with bare containers (Argo Workflow)	✗	✗	✗	✗	✓ via config	✓ via config
Can silence a wrong reading	✗	✗	✗	✗	n/a	✓
Rejects a containers lookalike	✓	✓	✓	✓	✓ path-exact	✓
1000 documents	144 ms	135 ms	171 ms	3058 ms	92 ms	107 ms
Binary	27.2 MB	27.2 MB	12.4 MB	25.4 MB	4.1 MB	12.6 MB
go.sum lines	74	74	72	109	42	78
Code generation	—	—	—	make schema	—	—
New CLI surface	—	—	—	--schema	--config	--config

One interleaved best-of-7 run; every variant emits the same 2000 images. Absolute timings drift with machine load between runs — the ratios are the stable quantity.

Approach

Keep the lookup — the kinds and paths are not wrong, they are just in Go, which is why a new one needs a release. Move them into configuration, as JMESPath expressions.

k8s/resources.yaml (embedded) lists each kind and where it holds images: podSpecs, containers (for resources holding bare containers), and documents (how a List unwraps its items, so that special case is two lines of config). --config merges a user's file over the built-in one, keyed by kind, so a custom resource can be added and a built-in corrected.

Why JMESPath rather than plain field paths

An earlier revision used a ~25-line hand-rolled resolver. For navigation the two are indistinguishable — and the built-in resources.yaml needed no edits when the resolver was swapped.

What field paths cannot express is selection. An Argo Workflow holds a list of templates, each with a container, a script, or neither:

resources:
  - kind: Workflow
    containers: ["spec.templates[*].[container, script][]"]

$ kir --config approvals/kir_test.TestCustomResource.config.yaml \
      approvals/kir_test.TestCustomResource.Workflow.input.yaml
builder:1.2.0
python:3.12

Multi-select and flattening are not field navigation, and the projection drops templates holding neither. Only this option and #106 find those images — #82 and #83 look for PodSpec shape, and a Workflow template's container is a bare container.

Also: expressions compile when the config loads, so a typo is an error naming the kind and field rather than one that silently matches nothing all run. Re-measured, the price of the dependency is 13 go.sum lines, 0.2 MB, ~1 ms per 1000 documents.

What it buys overall

Cheapest by every mechanical measure, because the lookup never has to decide anything: 92 ms against master's 144 ms, a 4.1 MB binary against 27.2 MB, and 42 go.sum lines against 74. Precision is exact by construction, with no schema or generated code to keep in step with the Kubernetes API — the v0.32.3 → v0.36.3 bump touched nothing here.

What it costs

It does not answer #26's second motivation on its own. A custom resource is invisible until somebody describes it, so every user of Argo, Knative, or an in-house CRD writes that file. TestCustomResource pins both halves deliberately — Undescribed yields nothing, Configured yields images. That is the gap #106 closes by inferring the shapes that can be inferred.

Notes for review

• Marked feat(podspec)! — --config locations are JMESPath. Plain field paths are unaffected; a literal key that needs quoting is not.
• One golden changes (shared with B, C and E): TestFailure.BadYAML's stderr gains an error converting YAML to JSON: prefix — same class, same exit 1.

gofmt, go vet, go mod tidy no-op, go test -race ./... green. ADR 0009 records the decision as proposed.