Expose canonical root and Git context in index_repository responses

[Tomauskasz]

What problem does this solve?

index_repository derives and returns a project name, but a successful response does not identify the canonical repository root or the Git checkout that was indexed.

This is ambiguous for clients that manage several linked worktrees of one repository. Each worktree has a distinct absolute root and must use its own graph, but the client cannot prove that the returned project maps to the leased worktree and expected commit. Falling back to another checkout's graph can return stale or incorrect code knowledge.

Proposed solution

On successful index_repository, return:

• root_path: the canonical root already used by the indexing request.
• The existing Git-context object produced by add_git_context_json, including the current commit and linked-worktree metadata.

The fields should survive direct, supervised, and daemon-coordinated indexing paths. Existing response fields and project naming remain unchanged.

Acceptance criteria

• Absolute and relative repository requests return the same canonical root_path.
• A linked Git worktree returns that worktree's canonical root and truthful Git/worktree context.
• Supervised and daemon forwarding preserve the fields.
• Production index_repository response tests cover these cases.

This change lets clients establish a strict readiness boundary: synchronous index, exact root/commit proof, then project-scoped graph queries.

Alternatives considered

• Infer identity from the returned project name: unsafe because names are normalized identifiers, not canonical root/commit proof.
• Reuse the main checkout's graph: unsafe because another worktree can be stale or at a different commit.
• Copy or share persisted graph artifacts: unsafe because project identity is embedded and concurrent worktrees can collide.
• Depend on asynchronous auto-indexing: it does not provide a synchronous readiness boundary.

Confirmations

• I searched existing issues and pull requests; this is not a duplicate.