fix(cli): survive ktx.yaml version skew and derive repo ownership from disk (#293)

* fix(cli): survive ktx.yaml version skew and derive repo ownership from disk

Loading ktx.yaml is now tolerant of keys this ktx version does not
recognize: they are stripped from the in-memory config (the file on disk
is never rewritten) and reported by ktx status as non-blocking warnings,
while invalid values on recognized fields still fail hard. Repo
ownership is derived from observed state (a .git directory plus a root
ktx.yaml) instead of a ktx.managed git-config marker, so projects
created by any past or future ktx classify identically. initKtxProject
now runs an explicit foreign-repo pre-check and writes ktx.yaml before
initializing git, so an interrupted init leaves only recoverable
residue instead of a bare .git misread as foreign.

* style(cli): trim comment blocks to constraint-only notes

* docs(agents): require constraint-only code comments

docs-site/content/docs/cli-reference/ktx-status.mdx

@@ -94,6 +94,6 @@ stats, and are always shown (they do not require external communication).
 |-------|-------|----------|
 | No **ktx** project found | Current directory has no `ktx.yaml` and `KTX_PROJECT_DIR` is unset | `ktx status` runs setup checks; run from a **ktx** project or set `KTX_PROJECT_DIR` for project checks |
 | Project config check fails | The project directory is missing or has an invalid `ktx.yaml` | Run `ktx setup` to resume setup |
-| Schema validation fails | `ktx.yaml` does not match the current config schema | Run `ktx status --validate --json` for structured issue details, then edit `ktx.yaml` or rerun `ktx setup` |
+| Schema validation fails | A field **ktx** recognizes has an invalid value. Unrecognized keys are reported as non-blocking warnings (exit `0`), not failures | Run `ktx status --validate --json` for structured issue details, then edit `ktx.yaml` or rerun `ktx setup` |
 | Semantic search check warns | Embeddings are not configured or the provider probe failed | Run `ktx setup` or inspect the check's `fix` field in JSON output |
 | Query history check warns | A database has query history enabled but the warehouse prerequisites are missing | Fix the warehouse extension, grants, or history access, then rerun `ktx status` |

docs-site/content/docs/configuration/ktx-yaml.mdx

@@ -666,11 +666,21 @@ agent:
 
 ## Validating your config
 
-**ktx** validates `ktx.yaml` strictly: unknown keys at the top level or inside
-strict blocks cause setup and CLI commands to fail with a precise path
-(`scan.relationships.acceptThreshhold: Unrecognized key`). Warehouse
-connections accept extra driver-specific fields, so passthrough values like
-`historicSql` and `context.queryHistory` are allowed.
+**ktx** validates `ktx.yaml` when it loads, and treats two kinds of problems
+differently:
+
+- **An invalid value on a field ktx recognizes** (for example
+  `llm.provider.backend: nope`) is a hard error. Setup and CLI commands stop and
+  report the exact path so you can fix it.
+- **An unrecognized key** — one left over from a different **ktx** version, or a
+  typo such as `scan.relationships.acceptThreshhold` — is tolerated, not fatal.
+  **ktx** ignores the key and keeps running, so a misspelled field quietly falls
+  back to its default instead of taking effect. `ktx status` lists each ignored
+  key as a warning (and exits `0`) so you can remove or correct it when
+  convenient.
+
+Warehouse connections accept extra driver-specific fields, so passthrough values
+like `historicSql` and `context.queryHistory` are allowed.
 
 To re-validate without running anything else: