fix(deploy): kates deploy --with-chaos=false puts the Kates API on the noop chaos provider, through a new chaos.provider chart value

[bmscomp]

Item 1.1 of the CLI performance and stability plan (finding F5, decision D1: noop). Independent of the other Wave 1 PRs.

Why

kates deploy --with-chaos=false installs no Litmus, but it left the Kates API on its litmus-crd default. Checked on main (6f4cf61):

• The flag is read for namespaces, chaosAlerts.enabled and the Litmus install (cli/cmd/deploy_components.go:383,1110,1838). The Kates helm call never mentions chaos.
• The kates chart had no chaos value. templates/configmap.yaml sets no KATES_CHAOS_PROVIDER, and extraEnv was the only knob.
• The backend defaults to kates.chaos.provider=litmus-crd (application.properties:275). ChaosCoordinator finds Litmus unavailable, logs at ERROR that fault injection is DISABLED, and falls back to noop. Disruption steps and resilience faults come back skipped, and the log reads like a broken install rather than one deployed without chaos.

Changes

charts/kates

• values.yaml: new chaos.provider, empty by default. It sits after the tests: block, so the values.yaml:395-405 and :605-673 caveat refs do not move.
• templates/configmap.yaml: renders KATES_CHAOS_PROVIDER only when the value is set. It sits after the cited :82-178 block. The pod's checksum/config annotation rolls the pod when the value flips.
• values.schema.json: chaos.provider is one of "", litmus-crd, kubernetes, hybrid or noop, the four @Named providers.
• Chart.yaml: 0.11.2, with the patch comment rewritten and a kind: added changes entry. appVersion stays 1.25.1.
• README.md: a chaos.provider row in the Core table, and the Chaos permissions example selects the direct backend with chaos.provider instead of extraEnv.

cli/cmd/deploy_components.go: katesChaosArgs adds --set chaos.provider=noop to the Kates helm call when --with-chaos=false and no chaos release is installed in the chaos namespace. With --with-chaos, or with an earlier Litmus release there, it adds nothing, and the chart default applies. A re-run with --with-chaos therefore puts the API back on litmus-crd, because helm upgrade resets the value.

Version tables: README.md chart table and docs/book/appendix-d-versions.md at 0.11.2.

.github/workflows/ci.yml: a helm-lint step renders the configmap with the value empty (no KATES_CHAOS_PROVIDER), set to noop (rendered), and set to litmus (refused by the schema).

Tests

Added:

• TestKatesChaosArgs: with chaos, nothing; without chaos and no release, --set chaos.provider=noop; without chaos and a chaos release installed, nothing.
• TestDeployCommand_SingleTopology (chaos off) asserts the Kates helm call carries --set chaos.provider=noop. TestDeployCommand_IsolatedTopology (chaos on) asserts it carries no chaos.provider.
• The ci.yml render step above.

Run locally, passing:

• cd cli && go test ./..., go test -race ./cmd, go vet ./.... TestMCPCaveatRefAnchors passes, so no cited chart line moved.
• golangci-lint run --new-from-rev=origin/main ./...: 0 issues.
• scripts/check-cli-style.sh and scripts/check-cli-compat.sh: OK.
• helm lint charts/kates/: 0 failed.
• helm template with the defaults and with values-dev, -generic, -kind, -local, -native-local, -native and -staging: each renders. values-prod and values-corporate render with externalDatabase.existingSecret set, as in CI.
• The new ci.yml step, run as a script: OK. --set chaos.provider=noop changes checksum/config.
• scripts/check-versions.sh, scripts/check-chart-test-paths.sh, scripts/gen-chart-table.sh --check, scripts/gen-version-matrix.sh --check: OK.
• actionlint, and yamllint -c .yamllint.yaml .github config charts: clean.
• scripts/check-book-style.sh, check-book-contrast.py, check-mermaid.sh: OK.
• The backend suite, which cli/** triggers (Build & Test): this PR touches nothing under kates/. ./mvnw test on main's kates/ tree ran 1,254 tests with 0 failures and 0 errors, once for all of Wave 1.

Skipped locally: the book's HTML and PDF renders, since the only book change is one version cell; govulncheck, since go.mod is unchanged.

CI only: ./mvnw verify with the *IT tests, kubeconform, the fetched-dependency chart renders, Kind and Docker jobs, CodeQL and Trivy.

Decisions

• noop, per D1. kubernetes with rbac.directChaos would keep POD_DELETE, rolling restart and scale-down working without Litmus, but it gives the API cluster write rights the user opted out of.
• Empty default rather than litmus-crd. An empty value renders nothing, so every existing release keeps its configmap byte for byte, and extraEnv users keep control.
• Compound runs are unchanged. POST /api/disruptions/compound picks each fault's provider by name (default kubernetes) and bypasses kates.chaos.provider, so this value does not touch them.

Deliberately not done

• docs/book/07-chaos-practice.md:117 still says to switch providers through extraEnv. That still works, because a container env entry overrides the configmap. Moving the book to chaos.provider is left for a docs PR.
• No live deploy: Docker is off here.