feat(citation): cite a source span, not the whole retrieved chunk

[mrsibe]

Stacked on #161 (refactor/160-v15-seams), because this uses the CitationCandidate contract from #160. Base will retarget to main once #161 merges.

What does this PR do?

Makes a citation point at the span that supports the claim, not at the whole retrieved chunk.

Why?

Today a citation's evidence is the entire chunk: citationFromSearchResult() set quote: result.content and startOffset/endOffset to the union of the blocks the chunk covered. Clicking [3] quoted ~500 characters and highlighted every block the chunk touched.

Aligning a citation to a claim after the answer is not solvable deterministically — deciding that "Transformer 不需要 RNN 结构" is supported by "Transformers eliminate recurrent connections" is semantic entailment (NLI), not substring/token/embedding matching. So the spans are produced before the answer, and the model selects among them by index.

Related issue

Fixes #155
Related to #154

What changed

• buildCitationCandidates() (src/main/services/citationCandidates.ts) turns each retrieved chunk into sentence-sized candidate spans:
  • sentence segmentation is deliberately conservative (3.14, U.S., Fig. 3, et al. do not split);
  • short neighbouring sentences merge (at most 3 sentences / ~80 chars) so a claim that needs two sentences is still citable;
  • candidates are numbered 1..M continuously across chunks — this number is the [n] the model writes and Citation.index carries, so the user-visible marker protocol is unchanged;
  • a chunk with no block provenance falls back to one whole-chunk candidate with no span (never worse than before).
• buildRAGContext() presents candidates grouped by source/chunk with globally continuous markers, and builds each Citation from its candidate, so quote / page / blockId / startOffset / endOffset describe the supporting passage.
• chatHandlers takes citationContexts from buildRAGContext instead of re-deriving the span from the chunk.

What is unchanged by design: [n], citationMarkers, resolveCitations, citationToSourceAnchor, Citation.index — the [n] → citation → reader chain is the same; only what [n] resolves to is finer.

How was this tested?

• npm run typecheck — passes.
• npm test — 352 pass, 0 fail (new test/citationCandidates.test.ts, rewritten test/citations.test.ts).
  • pinned: a candidate's quote is a verbatim slice of the source at its offsets (what the reader highlights);
  • pinned: grouping does not over-split (A causes B. So the result is C. stays one candidate);
  • pinned: global numbering across chunks and the blockless fallback.
• npm run build — passes.
• Eval baseline: RAG harness output is byte-identical to docs/eval/baseline-v1.4.json (retrieval is untouched by this change).

Not verified / scoped out

• Live-model behaviour. The prompt contract changed (the model now cites candidate spans), so the citation-marking rate should be watched against a real endpoint before v1.5 ships. No model was run here.
• Sub-sentence highlight in the PDF viewer. TextSourceReader highlights startOffset..endOffset exactly; PdfSourceReader highlights the containing paragraph (previously the chunk's first block). Mapping the parser's offsets onto the pdfjs text layer is a separate change.

Checklist

• I have reviewed my own changes.
• npm run typecheck passes.
• npm run build passes.
• I have tested the affected user workflow. (Unit + eval; live-model pass noted above.)
• I have not included unrelated changes.
• I have updated documentation when necessary. (Contracts carry the rationale inline.)

Desktop / build changes

• Not applicable