nvca: MiniService re-renders chart via ReVal after install and fails running instances on invalid render

Describe the bug

Component: NVCA agent, MiniService controller (src/compute-plane-services/nvca/internal/miniservice).

After a Helm MiniService install completes, the rendered chart (the ReVal /v1/render output) is kept only in a local gzip file cache (internal/miniservice/chartcache) backed by an emptyDir volume on the agent pod (pkg/operator/reconcile/nvcaagent_reconcile.go, volume reval-rendered-helmcharts). That cache is lost whenever the agent pod restarts or is rescheduled, and entries are LRU-evicted when the emptyDir hits ENOSPC.

When the cache misses, getRenderedData callers call ReVal again:

• collectObjectStatuses in internal/miniservice/status.go (used by both status modes) on every status reconcile of a Running instance
• prepareUpdateWorkload in internal/miniservice/reconcile.go during Helm values updates

render() in reconcile.go returns reconcile.TerminalError when ReVal answers valid=false. In Reconcile, a terminal error from doStatus moves a Running instance to phase Failed and the instance is cleaned up.

Consequences:

1. Unnecessary ReVal calls for already-installed instances.
2. A transient upstream ReVal problem, or a chart republished under the same URL, tears down a healthy running instance.

Steps or code to reproduce bug

1. Deploy a Helm-based function so a MiniService reaches Running.
2. Restart or delete the nvca agent pod (or fill the reval-rendered-helmcharts emptyDir to force LRU eviction).
3. Make ReVal return valid=false (for example, point the agent at a broken ReVal endpoint, or republish the chart with a validation error).
4. Observe that the next status reconcile calls reval.Render and the MiniService transitions to Failed and is cleaned up.

Expected behavior

NVCA should persist the rendered chart durably for the lifetime of the instance after the first successful render. Status checks must never call ReVal, and must never fail a running instance because of a re-render.

Additional context

A fix is in progress. Proposed approach:

• Persist the render output in a Secret in the instance namespace (gzipped, hash-annotated, owned by the MiniService).
• Remove the chartcache emptyDir volume from the agent pod.
• Downgrade terminal render errors during status checks to retryable errors so a running instance is never torn down by a re-render.

By submitting this issue, you agree to follow our code of conduct and our contributing guidelines.

Start in src/compute-plane-services/nvca/internal/miniservice/reconcile.go and status.go, then inspect internal/miniservice/chartcache and pkg/operator/reconcile/nvcaagent_reconcile.go. Trace getRenderedData, collectObjectStatuses, prepareUpdateWorkload, and the Running-to-Failed transition, then run the relevant NVCA tests. Done means rendered data survives agent restarts, status checks do not re-render, and a re-render failure cannot clean up a running instance.