Add explicit shared clusters across repos/worktrees

[sozercan]

This was generated by AI during triage.

Summary

Add an explicit sharing mode so multiple repos and/or git worktrees can intentionally target the same kindctl-managed kind cluster, instead of always deriving a private cluster from each repo/worktree path.

Motivation

Today kindctl's safe default is:

one repo/worktree path -> one derived cluster

That is ideal for agent isolation, but some local workflows need a shared integration cluster across several repos, for example:

• gateway, frontend, and service-a need to run against the same local platform cluster.
• Multiple worktrees need to test cross-service behavior against a shared set of CRDs/controllers.
• A developer wants private per-worktree clusters by default, but a named shared cluster for integration testing.

Sharing should be explicit so the default agent-safe isolation remains unchanged.

Proposed UX

Add a shared scope flag accepted by all cluster-targeting commands:

kindctl create --share platform
kindctl kubectl --share platform get pods -A
kindctl load --share platform myapp:dev
kindctl hibernate --share platform
kindctl resume --share platform
kindctl doctor
kindctl delete --share platform

Any repo/worktree using the same share key targets the same cluster.

Proposed semantics

• Default behavior remains unchanged: no --share means derive from the current repo/worktree path.
• --share KEY derives from the share key instead of the workspace root.
• Share keys are sanitized/capped similarly to --tag.
• --share and --tag can coexist if useful, e.g. --share platform --tag e2e, but this should be explicitly designed before implementation.
• Registry entries record shared ownership metadata, for example:

{
  "scope": "shared",
  "share": "platform",
  "roots": [
    "/Users/me/projects/gateway",
    "/Users/me/projects/frontend"
  ]
}

Safety requirements

• Sharing must be opt-in only.
• No arbitrary --name escape hatch should be introduced.
• Destructive commands still require registry ownership.
• nuke and prune must not touch unmanaged kind clusters.
• The global kubeconfig invariant remains unchanged: no code path reads or writes ~/.kube/config.
• kindctl list --workspace should make it clear when a visible cluster is shared vs private.

Acceptance criteria

• --share KEY works with create, delete, kubectl, exec, path, ctx, env, load, hibernate, and resume.
• Two different repos using the same --share KEY derive the same kubeconfig path and cluster name.
• Two different repos without --share still derive distinct private clusters.
• Repeated commands from the same shared scope reuse the existing shared cluster.
• Fast tests cover derivation, registry ownership, strict missing-cluster behavior, and destructive safety for shared clusters.
• Real kind E2E covers two separate git repos or worktrees sharing one real cluster.
• The global kubeconfig byte-identity test still passes.
• README and SKILL.md document when to use private vs shared clusters.