nvcf-compute-plane stack pin never auto-bumps with the collector it deploys

[kristinapathak]

Describe the bug

deploy/stacks/nvcf-compute-plane/environments/base.yaml pins the BYOO OTel
collector at 0.157.0-nv-0.2.1. The nvca-operator chart pins the same image
and is at 0.160.0-nv-0.2.5, because it has a deploys edge that auto-bumps it
on every collector release. The stack has no edge, so it never moves.

This is a diverging pin, not a stationary one: the two were equal in August, and
the gap grows by one release every time the collector ships.

It is inert today — the stack sets enabled: false — but enabling it hands out a
collector whose metrics writes get rejected (#1702, fixed in
v0.160.0-nv-0.2.5).

Steps or code to reproduce bug

$ tools/ci/chart-version-bumper --tag src/compute-plane-services/byoo-otel-collector/v0.160.0-nv-0.2.5
src/compute-plane-services/byoo-otel-collector/v0.160.0-nv-0.2.5 -> service byoo-otel-collector, version 0.160.0-nv-0.2.5
no chart declares that it deploys byoo-otel-collector; nothing to do

Nothing reports the stack as behind, and nothing moves it.

Expected behavior

A stack that repeats a chart's image pin auto-bumps with it, the same way the
chart does.

Additional context

Adding a deploys edge to the stack entry is not sufficient on its own. Two
lookups exclude it before it can be planned:

• ChartsDeploying (tools/chart-version-bumper/metadata.go) requires
  strings.HasPrefix(e.Path, ChartPrefix) with ChartPrefix = "deploy/helm/",
  so a deploy/stacks/ entry is never a candidate.
• PlanForValuesPaths (chart.go) then requires a Chart.yaml under the entry
  path. A stack is a helmfile tree with no chart of its own, and its charts sit
  at charts/*/Chart.yaml — two levels below where ChartFiles globs.

Both produce a silent no-op rather than a complaint, which is the same failure
shape #1697 fixed for nvca-operator ("no chart declares that it deploys
byoo-otel-collector; nothing to do").

A human edit confirms this will not be corrected incidentally: #1933 ("bump nvca
and operator to 3.10.0") edited the two lines directly above this pin —
nvcaOperator.imageTag and selfManaged.nvcaVersion — and left the collector
tag alone.

Note deploy/stacks/self-managed is covered by different machinery
(stack-pin-bump.yml / stack-pin-resolver, scoped to
deploy/stacks/self-managed/helmfile.d), which is why only this stack drifted.