feat(cli): introduce `ksail project` and migrate gitops-file commands off `ksail cluster`

[devantler]

🤖 Generated by the Daily AI Assistant

Problem

The top-level command taxonomy should reflect what a command operates on:

• ksail cluster — commands that operate on the cluster (lifecycle, connectivity, diagnostics).
• ksail workload — commands that operate on the workloads.
• ksail project — commands that operate solely on the GitOps files (the project structure), with no live cluster involved.

Today there is no ksail project group, and two commands that operate solely on GitOps files live under ksail cluster, where they don't fit the "operates on the cluster" meaning:

Command	Short	Operates on
ksail cluster init	"Initialize a new project"	GitOps files only (scaffolds ksail.yaml + the k8s/kustomize tree)
ksail cluster add-environment <name>	"Clone an existing cluster environment into a new one"	GitOps files only (clones an overlay under clusters/<env>/; the recent #5441 work is pure pkg/svc/environment file operations — no cluster is touched)

Both scaffold/transform project files without ever contacting a cluster, so by the taxonomy above they belong under ksail project.

The other ksail cluster subcommands correctly stay put — they all touch a live cluster or its access: create/update/delete/start/stop (lifecycle), list/info/diagnose/repair (inspection/repair), diff (drift vs the live cluster), connect (k9s), backup/restore (cluster state), switch (kubeconfig context), oidc (auth token).

Proposed direction

1. Add a new ksail project command group (pkg/cli/cmd/project/) registered on the root command, alongside cluster/workload/operator/tenant/open.
2. Move the GitOps-file commands under it: ksail project init and ksail project add-environment. The command implementations (pkg/svc/scaffolder, pkg/svc/environment, …) are unchanged — this is a CLI-surface reorganization, not a behaviour change.
3. Backward compatibility (decision needed): keep ksail cluster init / ksail cluster add-environment as deprecated hidden aliases that delegate to the new commands and print a deprecation notice for one or more releases, then remove them — versus a clean break. Given these are user-facing entry points (docs, scripts, the DevContainer, CI examples all reference ksail cluster init), a deprecation window is the safer default unless you'd prefer the clean break.
4. Definition of done for each move — a CLI reorg fans out across generated surfaces, so each moved command updates them in the same PR:
   • regenerate the command docs (ksail project * MDX) and remove/redirect the old cluster pages,
   • regenerate the MCP tool surface + chat docs_generated.go (toolgen),
   • refresh the go-snaps help-tree + tool-surface snapshots (UPDATE_SNAPS=true),
   • update in-repo references (README, AGENTS.md, DevContainer, examples) from ksail cluster init/add-environment to ksail project ….

Acceptance criteria

• ksail project init and ksail project add-environment exist and behave identically to today's ksail cluster equivalents.
• The ksail cluster group no longer owns these two commands (either removed or delegating deprecated aliases per the decision above).
• All generated surfaces (docs, MCP/chat tool surface, help + tool-surface snapshots) are regenerated and consistent; no drift.
• All in-repo references and examples point at the new ksail project … commands.
• ksail cluster retains only cluster-operating commands; the three groups match the taxonomy above.

Suggested decomposition (epic → children)

1. Scaffold the empty ksail project group + root wiring (+ docs stub). Smallest first slice.
2. Move init → ksail project init (with the chosen compat strategy) + regenerate all surfaces + update references.
3. Move add-environment → ksail project add-environment likewise.
4. Docs/reference sweep + remove the deprecation shims once the window closes (later release).

Open question (your call)

ksail workload gen (pkg/cli/cmd/workload/gen) also generates GitOps files rather than operating on a running workload, so by the same taxonomy it might belong under ksail project too. Out of scope for this issue as written (you scoped the move to ksail cluster → ksail project), but flagging it in case you want the reorg to cover it — happy to fold it in.