ksail silently ignores unknown ksail.yaml keys, so a typo'd opt-in flag reads as success

> 🤖 Generated by the Agentic Engineer

## Evidence

`ksail` silently ignores unknown keys in `ksail.yaml`. Measured against a binary built from
`codex/ksail-eks-upgrade-6925` @ `a333b570`, three configs differing only in one key produce
**byte-identical** behaviour — all three print `✔ config loaded` and proceed:

| `spec.cluster.eks` key | Result |
|---|---|
| `experimentalControlPlaneUpgrade: true` (correct) | `✔ config loaded` |
| `experimentalControlPlaneUpgradeTYPO: true` | `✔ config loaded` — no warning |
| `spec.cluster.totallyBogusTopLevelField: 12345` | `✔ config loaded` — no warning |

So the tolerance is general, not specific to one block. It is long-standing behaviour, not a
regression — it was found while reviewing #6930, not caused by it.

## Affected audience and impact

Anyone configuring ksail declaratively. The cost is highest for **opt-in flags**, where the failure is
silent and inverted: the operator writes the flag, ksail reports success, and the feature stays off.
They then conclude the *feature* is broken rather than their spelling. `eks.experimentalControlPlaneUpgrade`
is exactly this shape — a single misspelling leaves an experimental capability disabled with no signal
anywhere.

It also weakens every "set this field" instruction in the docs, because a typo is indistinguishable
from a correct configuration at the only point the user gets feedback.

## Expected behaviour

An unknown key in `ksail.yaml` should be surfaced. ksail's own validation already models the good
shape elsewhere — the `apiVersion` error names the field *and* the fix:

```
✗ error: apiVersion does not match expected value
field: apiVersion
fix: Set apiVersion to 'ksail.io/v1alpha1'
```

An unknown key should read the same way, ideally with a nearest-match suggestion
(`experimentalControlPlaneUpgradeTYPO` → did you mean `experimentalControlPlaneUpgrade`?).

Rejecting outright is the stricter option and would make the secure/correct path the default one; a
warning is the compatible option. That choice is the main thing to settle — a hard failure could break
existing configs that carry stray keys today.

## Acceptance criteria

- A `ksail.yaml` containing an unknown key produces a diagnostic naming the key and its path.
- The diagnostic names the fix, matching the existing `field:` / `fix:` presentation.
- Tests cover a misspelled nested key and an unknown top-level key, both asserting the message.
- The chosen strictness (reject vs warn) is recorded, with the compatibility reasoning.

## Size

Small-to-medium. The generated JSON schema already enumerates every valid field, so the check can be
driven from it rather than hand-maintained.

Start at the ksail.yaml loading and validation entry point and inspect the generated JSON schema; compare its handling with the existing apiVersion diagnostic. Add coverage for a misspelled nested key and an unknown top-level key, verifying that both diagnostics name the path and fix, and document whether validation rejects or warns.

Written by the indexing model from the issue text.