kars upgrade recovery: in-cluster context ConfigMap, pending-release unstick, and --repair

Follow-up from the kars-upgrade-flow review.

For a cluster broken by a previous buggy CLI, remaining recovery gaps:

1. **Context bound to one machine:** `kars upgrade` aborts without `~/.kars/context.json` and tells you to 'run from the machine that deployed the cluster' — single point of failure for a team-operated product. Reconstruct context from a controller-owned ConfigMap (`kars-system/kars-release`: acrLoginServer, aksCluster, resourceGroup, foundryEndpoint, deployed release) so any authorized operator can upgrade/rollback from anywhere. This also gives version detection a visible, coupled home (vs the current 'dead' `karsRelease` Helm value).
2. **Stuck Helm release:** `kars up` cleans `pending-install` secrets; `kars upgrade` has no equivalent. A `pending-upgrade`/`failed` release makes `helm upgrade --atomic` abort with 'another operation in progress' and no in-tool unstick. Add the same cleanup / `helm rollback`-to-last-deployed before the atomic upgrade.
3. **No `--repair`:** add an idempotent 'put me back exactly on the version I'm supposed to be on' path (re-import current marker's images + re-apply + restart, skipping the version compare).
4. **Downgrade safety:** a stale version marker could silently move a *security* runtime backwards; consider requiring an explicit, loud `--allow-downgrade`.

Severity: P1/P2 (reliability/recovery).

Start by tracing the kars upgrade flow and the existing kars up cleanup for pending Helm releases. Define how the kars-system/kars-release ConfigMap supplies context and version data, then map the repair and downgrade-safety paths. Done means authorized operators can recover context, unstick releases, run --repair, and require explicit approval for downgrades.

Written by the indexing model from the issue text.