perf(grouping): return file indices instead of paths (#1209)

The grouping LLM call asked the model to echo full file paths back in its
JSON response, making the output size proportional to the sum of all path
lengths. On large change sets this overflowed the completion token limit;
the truncated JSON then failed to parse and the whole change set degraded to
per-file dispatch, multiplying downstream review calls.

Switch the grouping contract to integer indices:

- buildFileList prefixes each file with a zero-based index, e.g.
  "[0] MODIFIED path (+12/-3)".
- groupingResponse.Files is now []int; the model returns those indices.
- parseGroupingResponse maps indices back to diffs by position, skipping
  out-of-range indices (the index equivalent of the previous unknown-path
  skip) and duplicates. A parse failure still returns an error and the
  caller falls back to per-file dispatch, exactly as before.
- Prompts updated to ask for integer indices.

The response is now an order of magnitude smaller, so truncation on large
change sets becomes rare instead of common.

Because the grouping response is now indices, the session viewer resolves
them back to paths for display:

- buildGroupingIndex scans the request's numbered file list (user message
  only) to build an index->path map.
- parseGroupingGroups unmarshals the response into indices; a legacy
  path-string response reports not-ok so the viewer keeps showing the raw
  text (already readable for those older sessions).
- groupingView maps indices to paths and falls back to the raw response
  when nothing resolves (format drift), avoiding a wall of "#idx".
- The grouping card renders label + resolved paths with a collapsible raw
  response for audit. No on-disk format changes; existing sessions render
  retroactively.