perf(semantic): exact, cheaper doc-section candidate scoring

[DeusData]

The doc-section candidate pass from #2574 made indexing the Linux kernel about 2.8x slower: 207 s before #2574 and 580 s after it, same machine, same build. A teammate's call trees put about 85 % of that time in the per-candidate dot products and about 14 % in sorting.

What changes (output unchanged)

• Dot product. Each section's term vector is kept as a dense array per worker, so a candidate's dot product reads only the candidate's own 20–60 terms. Before, it merged them with the section's up to 1,024 terms. The products and the order of addition are the same, so every score is the same float.
• Sorting. Only the candidates the results actually read are sorted: the top 10, plus every candidate scoring 0.20 or more (the "local" hits) for functions, and the top 3 for files. The comparator cmp_doc_cand is a total order, so sorting this subset gives exactly the same first entries as the full sort did.

Measured

• Linux kernel (perf-bench/linux, M5 Pro, same plain build, quiet machine): 579.7 s → 391.5 s. Nodes (8,540,291) and edges (16,765,478) are identical.
• Exactness was checked directly. A scratch build ran the old merge dot product and the old full sort next to the new code on django: 0 score differences (bitwise), 0 shared-term differences and 0 order differences over 5,003 sections.
• Suites: semantic, pipeline, pipeline_semantic_manifest_repro, store_arch, mcp all pass. cppcheck 2.20, clang-format and the memory-core lint are clean.

Not in this PR

• Remaining cost: candidate generation is unchanged. A term counts as a key term when at most one in 20 functions uses it, so on the kernel that's tens of thousands of functions per term. Narrowing that would change the stored rows, so it needs its own decision.
• Run-to-run differences in doc_link_candidates: the kernel A/B also showed these, but they come from main itself (two runs of the same build differ). The cause is in the reST section text (rst_body); a separate fix follows.