Future: promote cluster-targeting config from local to core when hosted clusters land

[kreneskyp]

Context

In the StR-005 / FR-020 core plugin schema (branch `feat/shared-config-secrets`), we deliberately kept cluster-targeting settings (cluster context, kindClusterName, internal/external base domains) inside `packages/local` rather than promoting them to the `core` plugin schema.

Rationale: today `local` is the only "cluster" the CLI talks to (a local kind cluster). Putting a `core.cluster.context` setting in the schema now would be speculative — there's no hosted alternative to switch to.

Trigger

This issue should be picked up when hosted Agent IX clusters land and `ix up ` (or any other command) needs to ask "local or hosted?" The right answer at that point is to promote a small set of cluster-context settings from `local` to `core` so every plugin can read them through one canonical place.

Likely scope (when triggered)

• Promote `cluster.context` (or equivalent name) into `core` schema. Values include:
  • `local` (kind cluster — current default)
  • `hosted-` (hosted Agent IX clusters when they exist)
  • User-named contexts pointing at arbitrary kubeconfig contexts
• Decide what stays in `local` (kind-specific: `kindClusterName`, `internalBaseDomain`, `externalBaseDomain`) vs what moves to `core` (`cluster.context`, possibly `cluster.namespace`).
• Ensure cross-plugin readers (`local`, `elements`, future hosted plugin) all read context from the same place.
• Migration path: existing `local` users have implicit `local` context; explicit `core.cluster.context` set on first command of v0.x+1.

Out of scope

• Multi-cluster commands (`ix --cluster=hosted up `) — that's a CLI flag/UX concern, not a schema concern; can be added independently.
• Kubeconfig path overrides — those are already env-driven (`KUBECONFIG`); no need for ix-cli to own them.

Related

• Branch `feat/shared-config-secrets`, FR-020 (core plugin schema).
• Issue Future: stricter plugin isolation (Terraform-style subprocess+RPC model) #1 (Future: stricter plugin isolation) — orthogonal but related v2 work.