Kubernetes monitoring is a core reference for a feature only one deployment target uses

`KubernetesClient.dll` is 10.1 MB, the largest single assembly in the published image. Marten is 2.7 MB and `barakoCMS.dll` itself is 1.2 MB. An application's own code being the eighth largest thing in its image, behind a cluster client it only uses on one deployment target, is the smell worth acting on.

It is already optional at runtime: `Kubernetes__Enabled` gates it. It is not optional at build time, and the repository's own rule is that optional things are modules that depend on the core, never core references that a deployment happens not to switch on.

**Be honest about the size argument up front.** Uncompressed it is 10.1 MB of a 464 MB image. Compressed, which is what anyone actually downloads, `KubernetesClient.dll` is 2.3 MB of a 115.6 MB pull, about 2%. Swapping the base image from `aspnet:10.0` (88.1 MB compressed) to `aspnet:10.0-noble-chiseled-extra` (63.9 MB) saves 24.2 MB, ten times more, for a one-line change. File this for the architecture, not for the megabytes, and do the base swap separately.

### The surface is small

| File | Lines | Moves? |
| --- | --- | --- |
| `Infrastructure/Services/KubernetesClientProvider.cs` | 96 | yes |
| `Infrastructure/Services/KubernetesMonitorService.cs` | 167 | yes |
| `Features/Monitoring/Kubernetes/Endpoint.cs` | 37 | yes |
| `Extensions/ServiceCollectionExtensions.cs:872` | 1 | the DI registration goes with them |

Three that only mention it and stay: `Infrastructure/Security/JwtKeyGuard.cs` (a comment about the placeholder in `k8s/02-secret.yaml`, unrelated to the client), `Features/Settings/UpdateSetting.cs:99` and `:109` (categorises setting keys by prefix, and would be describing a setting the core no longer owns), and the doc comment on `SystemCapabilities.cs:106` which names the cluster view in `ViewMonitoring`'s description.

No new capability. The endpoint already gates on `ViewMonitoring`, which the core owns and keeps.

### Three consequences, and the third is the real decision

**1. It is a breaking HTTP change.** `GET /api/monitoring/k8s` leaves the core. Section 6 says removing a route moves `ApiContract.Version`, which is 2 today.

**2. barakoBrew has to degrade.** `useKubernetesStatus()` in `src/hooks/use-monitoring.ts:48` feeds a Kubernetes panel in `src/app/(admin)/ops/health/page.tsx:87`. Against a core without the module that call is a 404, and the panel must hide rather than render an error, which is the same distinction between "the request failed" and "nothing is there" that brew #94 fixed elsewhere. Filed separately.

**3. If the published image references the module, the saving is zero.** That is the whole tension. This repository ships `k8s/` manifests, so Kubernetes is a supported deployment target, and those manifests deploy `ghcr.io/baryodev/barako-cms`. Either:

- the default image drops the module, a Kubernetes operator adds the package and builds an image, and the endpoint 404s on the official image; or
- the default image keeps it, the architecture is cleaner, and nothing gets smaller.

Section 3 also says a config default must preserve existing behaviour, and extracting to an opt-in module is exactly turning something off for every existing deployment. So whichever way this goes, it is a deliberate break that gets called out in the release, not a quiet refactor.

Worth deciding before any code moves.

Start with the architecture sections 3 and 6, then inspect the listed Kubernetes provider, monitor service, endpoint, and DI registration files alongside the published image and k8s manifests. Determine whether the module and route should be extracted and how the official image behaves; done means the architecture decision, API version impact, deployment behavior, and release communication are explicitly recorded.

Written by the indexing model from the issue text.