chore(deps): omni/client 1.10.4 is unsatisfiable — Talos beta.1 needs k8s 0.37 while the vcluster stack pins 0.36

> 🤖 Generated by the Agentic Engineer

## Evidence

Dependabot [#6724](https://github.com/devantler-tech/ksail/pull/6724) (`github.com/siderolabs/omni/client` 1.9.1 → 1.10.4) fails **39 checks** — the whole Go pipeline. It is not a flake and not a KSail regression: the bump is unsatisfiable against the rest of the dependency graph.

The chain, each link verified against the module proxy and a local build at the PR head (`cac78b6de9`):

1. `omni/client@v1.10.4` **requires** `talos/pkg/machinery@v1.14.0-beta.1` (its `go.mod`). `v1.9.1` required `alpha.1`, so the machinery bump is transitive and unavoidable.
2. Machinery `beta.1` moved `Kubelet` and `CoreDNS` out of `MachineConfig`/`ClusterConfig` into their own documents (`K8sKubeletConfig`, `K8sCoreDNSConfig`). Our pinned `github.com/siderolabs/talos@v1.14.0-alpha.2` **does not compile** against it — the failure is inside *upstream's own* package:
```
talos@v1.14.0-alpha.2/pkg/images/list.go:43: config.Cluster().CoreDNS undefined
talos@v1.14.0-alpha.2/pkg/images/list.go:45: config.Machine().Kubelet undefined
```
3. Bringing them into lockstep (`talos@v1.14.0-beta.1`) resolves that, but `talos@beta.1` **requires `k8s.io/* v0.37.0-beta.0`** (vs `v0.36.2` at `alpha.2`), which `go get` then applies across the tree.
4. `k8s.io/apiserver@v0.37.0-beta.0` changes `rest.RESTUpdateStrategy`:
```
have AllowCreateOnUpdate() bool
want AllowCreateOnUpdate(context.Context) bool
```
That breaks `github.com/loft-sh/apiserver`, reached via
`pkg/svc/provisioner/cluster/vcluster` → `loft-sh/vcluster/pkg/cli` → `loft-sh/apiserver` (`go mod why`).

## Why we cannot fix this ourselves

- `loft-sh/apiserver` has **no tagged releases at all** (`proxy.golang.org/.../@v/list` returns HTTP 200 and an empty body; control: `loft-sh/vcluster` returns tags). Its version is a pseudo-version pinned by vcluster, so there is nothing for us to bump to.
- Even the newest **`vcluster@v0.37.0-rc.3`** still requires **`k8s.io/apiserver v0.36.0`**. We are on `v0.35.2`, so upgrading vcluster does not help either — the whole vcluster stack is still on k8s 0.36.

So Talos `v1.14.0-beta.1` (k8s 0.37) and the vcluster stack (k8s 0.36) cannot currently coexist in one module graph. KSail embeds both.

## Impact

`omni/client` cannot be updated, and any future Talos SDK bump past `v1.14.0-alpha.2` hits the same wall. This is a standing ceiling on two dependency lines, not a one-off. It also means #6724 will keep re-appearing and re-failing until the upstreams align — worth recording so each tick does not re-derive it.

Adapting our own code is *not* the missing piece: 12 KSail call sites move (`Kubelet`, `CoreDNS`, `Cluster().Endpoint`, `Cluster().IssuingCA`), which is ordinary work — the blocker is strictly the `loft-sh/apiserver` break, which is outside our control.

## Expected behaviour

`omni/client` tracks upstream releases like every other dependency, without forcing an incompatible k8s minor across the graph.

## Acceptance criteria

- `go build ./...` succeeds with `omni/client@v1.10.4` (or later) and a Talos SDK matching its required machinery.
- The `vcluster` path still builds — no `loft-sh/apiserver` signature break.
- The 12 Talos multi-document call sites are migrated as part of whichever bump lands.

Rough size: **S** once upstream aligns (mechanical call-site migration); **not startable** before then.

**Blocker:** loft-sh/apiserver k8s-0.37-compatible release | upstream | last-verified 2026-09-15: not shipped (re-checked 2026-09-15 via the module proxy: `@latest` still `v0.0.0-20260903125814-2353e4b52582`; previously re-checked 2026-09-14 against the `loft-sh/vcluster` `@v/list` control, 9463 bytes: proxy `@v/list` still empty, `@latest` still `v0.0.0-20260903125814-2353e4b52582`). `loft-sh/apiserver@latest` is still `v0.0.0-20260903125814-2353e4b52582` (unmoved since 2026-09-03) and still publishes **no tags at all** (proxy `@v/list` returns HTTP 200 with a 0-byte body; control: `loft-sh/vcluster` returns 9463 bytes), so there is nothing to bump to and the `AllowCreateOnUpdate() bool` vs `AllowCreateOnUpdate(context.Context) bool` mismatch against `k8s.io/apiserver` 0.37 is unchanged. **New this check, and it settles the open question the previous record left:** vcluster has left the release-candidate series — `@latest` is now the **stable `v0.37.0`** (tagged 2026-09-08T17:46:09Z), not rc.5. Its `go.mod` is **byte-identical to rc.5** on every line that matters: `k8s.io/api`, `k8s.io/apiserver` and `k8s.io/client-go` are all still `v0.36.0`, and the indirect `loft-sh/apiserver` pin is still `v0.0.0-20260707184419-aef558a5ae8d`. So the stable release does **not** move the stack to 0.37 either — waiting for vcluster to leave rc was never the path out, and only a tagged k8s-0.37-compatible `loft-sh/apiserver` is.

Start with go.mod and run go build ./... at the dependency versions described. Inspect pkg/images/list.go and the pkg/svc/provisioner/cluster/vcluster path to confirm the Talos and vcluster failures. This is not startable until loft-sh/apiserver supports Kubernetes 0.37; done means the dependency bump, 12 call-site migrations, and both build paths succeed.

Written by the indexing model from the issue text.