feat(kube/operator): add --timeout and --no-atomic flags to 'kube operator install'

Nobody has claimed this yet.

## Context

`kube operator install` drives the solo-operator Helm release with hardcoded `Atomic: true`, `Wait: true`, and `Timeout: helm.DefaultTimeout` (`internal/workflows/steps/step_solo_operator.go`, `DeployChart` call). There is no way to adjust the timeout or opt out of atomic behaviour, which causes friction on slow or flaky environments and when debugging a failing install:

- **Slow private-image pulls** can exceed the fixed timeout, so Helm rolls back an install that would have succeeded with more time.
- On failure, atomic **deletes the rolled-back resources**, so the failed pods/events are gone and the operator cannot see *why* it failed (bad image, missing pull secret, OOM, …).
- If the atomic rollback is itself interrupted or times out, the release can be left in a `pending-*` state, which then blocks the next install with "another operation (install/upgrade/rollback) is in progress".

> Note: the *recovery* path for the pending-lock is already handled on PR #1060 — `kube operator uninstall` now clears a release in any state (not just `deployed`), and the install error carries a reason + remediation hint. This ticket is the ergonomics/debuggability follow-up, not a correctness fix.

## Proposed change

Add two flags to `kube operator install` (keeping the production-safe defaults):

1. **`--timeout`** — Helm wait timeout, default `helm.DefaultTimeout`. Follow the block-node convention (`internal/blocknode/chart.go` uses `ResolveHelmTimeout()`), so slow image pulls can be given more time without losing atomic safety.
2. **`--no-atomic`** (default **off**) — disable atomic + wait so a failed install leaves its resources in place for inspection. A non-atomic failed install leaves the release `failed`/`deployed` (recoverable by re-running install or `kube operator uninstall`) rather than risking a `pending` lock. `Atomic: true` stays the default — it is the correct production behaviour (no half-broken operator).

## Acceptance criteria

- [ ] `kube operator install --timeout ` overrides the Helm wait timeout; default unchanged.
- [ ] `kube operator install --no-atomic` sets `Atomic=false` (and `Wait=false`); default run keeps `Atomic=true`, `Wait=true`.
- [ ] Both flags are wired through `DeployChartOptions` in `internal/workflows/steps/step_solo_operator.go`.
- [ ] `docs/commands/README.md` (kube section) flag table + example updated, and the flag descriptions match `cmd/cli/commands/common/flags_common.go` and `--help` (per the repo docs rule).
- [ ] Descriptions make clear `--no-atomic` is a debugging aid and leaves resources behind on failure.

## Pointers

- Flags: `cmd/cli/commands/kube/operator/install.go`, `cmd/cli/commands/common/flags_common.go`
- Helm options: `internal/workflows/steps/step_solo_operator.go` (`DeployChart` call), `pkg/helm` (`DeployChartOptions.Atomic/Wait/Timeout`)
- Convention reference: `internal/blocknode/chart.go` (`ResolveHelmTimeout()`)

Start with cmd/cli/commands/kube/operator/install.go and the flag definitions in cmd/cli/commands/common/flags_common.go, then compare internal/blocknode/chart.go's ResolveHelmTimeout() convention. Trace the DeployChart call in internal/workflows/steps/step_solo_operator.go and the Atomic, Wait, and Timeout options in pkg/helm. Verify --help and the documented kube flag table and example; done means both flags preserve safe defaults while applying the requested timeout and non-atomic behavior.

Written by the indexing model from the issue text.