feat(cluster): scaffold and grow multi-cluster, multi-provider GitOps repos

> 🤖 Generated by the Daily AI Assistant

## Problem

`ksail cluster init` scaffolds **one** cluster for **one** provider, and `ksail tenant create` scaffolds a tenant. But a real platform is inherently **multi-cluster / multi-provider** (e.g. a local Docker dev cluster + a prod cloud cluster sharing one base), and ksail has no first-class way to scaffold or grow that shape. Consumers fall back to hand-maintained Kustomize/Flux boilerplate and "copy-the-prod-folder" recipes.

This is drawn from a real consumer — the `devantler-tech/platform` repo (Talos+Docker local, Talos+Hetzner prod, shared base, Flux GitOps). Its README literally asks: *"If you know of a different way to manage kustomize and flux kustomizations that results in less boilerplate code, please let me know."*

## Evidence — what the platform hand-maintains today

In `devantler-tech/platform`:

- **Sentinel + per-cluster `replacements:` boilerplate.** `k8s/clusters/base/` defines shared Flux Kustomizations with `__CLUSTER__` / `__PROVIDER__` sentinels; each environment overlay (`k8s/clusters/local/kustomization.yaml`, `k8s/clusters/prod/kustomization.yaml`) repeats a near-identical ~80-line `replacements:` block to rewrite those sentinels. Adding a cluster means copying that block.
- **Per-cluster bootstrap kustomization that differs by one line.** `k8s/clusters/local/bootstrap/kustomization.yaml` vs `…/prod/bootstrap/kustomization.yaml` are identical except for the provider path (`providers/docker/bootstrap` vs `providers/hetzner/bootstrap`).
- **Per-cluster Flux timeout patches.** Each overlay re-declares strategic-merge patches that override `spec.timeout` on the four Flux Kustomizations (`bootstrap → infrastructure-controllers → infrastructure → apps`).
- **A documented "fork + edit N inputs" / "cp -R" onboarding.** `docs/TEMPLATING.md` enumerates the ~6 inputs a fork must edit; adding an environment is described as *"`cp -R k8s/clusters/prod k8s/clusters/` … `cp ksail.prod.yaml ksail..yaml` … edit."*

None of this is provider- or app-specific business logic — it's the cross-environment **wiring** that ksail already understands conceptually (it owns `distribution`, `provider`, `kustomizationFile` per config).

## Proposed direction (incremental, behind existing primitives)

1. **`ksail cluster add-environment --from `** — clone an existing cluster overlay + its `ksail..yaml`, rewrite the cluster/provider identifiers, and wire the new Flux Kustomization paths. Removes the manual `cp -R` + sentinel/replacement edit.
2. **Multi-cluster mode for `cluster init`** — optionally scaffold the shared-base + provider-overlay + per-cluster-overlay layout (with the sentinel-substitution already wired) instead of only the single-cluster source dir.
3. **(Stretch) Declarative expansion** — let a config declare its `environments` × `providers` and have ksail generate the Flux Kustomization dependency wiring and per-cluster timeout knobs, so consumers stop hand-writing `replacements:` and timeout patches.

## Rough size

Large / epic — ship incrementally (1 → 2 → 3); item 1 alone removes most of the per-environment toil. Relates to the roadmap epic #4988; complementary to #5344 (validation depth) and the existing single-cluster `cluster init` + `tenant create`.

*Filed from a holistic platform↔ksail review. The platform is the motivating real-world consumer; happy to dogfood any design against it.*

Start with the existing `cluster init` and `tenant create` entry points and compare the platform paths described under `k8s/clusters/` with the `ksail..yaml` configuration files. The first increment is `cluster add-environment --from `; done should include cloning an overlay and configuration, rewriting cluster/provider identifiers, and wiring the new Flux Kustomization paths.

Written by the indexing model from the issue text.