index_status(verbose) reports the live repo head_sha, not the indexed generation — misleading freshness signal

[PsyTech-Rob]

Environment: v0.10.2, Windows 11, daemon mode, --mode full.

Symptom

index_status(verbose=true) returns git.head_sha (and branch info) read from the live repository, not from the indexed generation. Sequence observed:

1. Index built at generation T0 (HEAD = dbbec50…).
2. New commit 34d6c6f… lands; the watcher has not yet reindexed — node count and graph content are still T0, and check_index_coverage still reports metadata.generation = T0.
3. index_status(verbose=true) already reports head_sha = 34d6c6f….

A freshness poll keyed on head_sha therefore declares "index up to date" while the graph is stale. Also mildly surprising: non-verbose index_status omits the git block entirely, so the same poll silently compares against an empty field forever.

Suggestion

Expose the indexed generation's commit alongside the live one — e.g. git.head_sha (live) + git.indexed_sha (what the graph was built from; coverage already exposes metadata.generation as a timestamp). That gives clients a truthful staleness signal: indexed_sha != head_sha ⇒ stale.

[DeusData]

Thank you @PsyTech-Rob. Confirmed on current main: verbose index_status calls add_git_context_json() against the live root_path at request time, while the published generation does not persist the checkout identity it indexed. The reported head_sha can therefore look current even when the graph represents an older checkout.

#1561 proposes the corresponding persisted-generation and bounded live-checkout evidence. This is routed priority/high; because it already has a linked implementation PR, it intentionally skips separate epic grouping.