fix(git): give each ktx project its own git repo root

A ktx project assumes its config dir is its own git working-tree root: writes,
session worktrees, squash-merges, and reindex scans all resolve relative to it.
GitService.initialize() gated on checkIsRepo() (IN_TREE), which is also
satisfied by an *enclosing* repository — so a project nested inside another git
working tree silently operated against the outer repo. Worktree/ingest writes
landed at the outer root (e.g. <outer>/wiki/global/) while reindex scanned
<projectDir>/wiki/global/, so the wiki was seeded but never indexed:
wiki_search returned nothing and knowledge_pages stayed empty, with no error.
Semantic-layer and raw-sources had the same divergence.

Gate initialization on checkIsRepo('root') instead: require the repo root to be
the config dir itself, and initialize a dedicated repository there when it is
not (logging clearly when nesting inside an existing repo). This restores the
one-repo-per-project invariant at the shared git layer, fixing all artifacts at
once, and keeps ktx's commits out of the enclosing repository.

docs-site/content/docs/guides/reviewing-context.mdx

@@ -59,6 +59,14 @@ and replay; it belongs in `.gitignore`. If your team wants a record of *why* a
 change happened, link the transcript path in the PR description rather than
 committing the file.
 
+**ktx** maintains its own git repository at the project directory. When the
+project lives inside an existing repository (for example a `data/ktx`
+subdirectory of your application repo), **ktx** initializes a dedicated
+repository at the project directory rather than committing into the enclosing
+one — its ingest commits stay isolated, and writes and reindexing always share
+the same working-tree root. Track the project directory in your outer repo as a
+nested checkout (or keep it separate) depending on how you want to review it.
+
 ## A typical review session
 
 The loop above describes the shape. In practice, one review session looks like