fix(explain): scope-filtered candidates leak their summary to the viewer

[kai392]

What changed

explain_ranking sources candidate summaries from the scoped hit set
instead of the pre-scope fused set. one word in the dict comprehension; the
candidate list itself is unchanged.

Why

the candidate loop deliberately walks every hit the pipeline saw, so a dropped
artifact is still explained rather than silently missing. but summaries was
keyed off that same pre-scope set, so the summary rode along for candidates
filter_hits had just removed. the result is that a viewer gets back the text
of artifacts kb.search and kb.context withhold from it — the module
docstring promises exactly the opposite:

Viewer scoping runs through the same filter_hits as kb.context, so a
caller cannot see a candidate it could not already retrieve.

same viewer, same query, on test before this patch:

=== kb.search as an outsider viewer ===
    (nothing)
=== kb.explain_ranking as the SAME viewer ===
    id=c-secret  gate=scope-filtered  summary='acme-example quarterly revenue projection is 4.2 million'

kb.explain_ranking is registered on all four surfaces — the mcp tool, the
jsonl handler, METHODS, and the cli — and on the remote transports the
viewer arrives as a request param, so this is the read path that answers with
content the sibling read paths refuse.

worth being precise about the severity: scoping.py says retrieval surfaces
treat scope as a relevance filter and artifacts stay readable as plaintext
on disk, so this is not a local privilege boundary. it matters for the
multi-project and remote-transport shapes — the same reason kb.audit grew
viewer scoping and tests/test_audit_scoping.py — and for the scoped-token
work in #608, where the viewer stops being caller-declared.

What might break

nothing on disk, no method signature changes, no kb.* shape change — the
summary key is still always present, just "" for a candidate the viewer
could not retrieve.

the deliberate part of the design is preserved on purpose. i read
test_scope_filtered_candidate_is_attributed_to_scope as pinning intent:
listing the hidden candidate and naming its gate is what makes the report
useful for tuning. so the row, the scope-filtered gate and the stage list
all stay exactly as they were — that test passes untouched. only the text is
withheld. if you'd rather drop such candidates from the report entirely, say
so and i'll switch it, but that would reverse a choice #628 looks to have
made on purpose.

VEP

not a surface change — no vep.

Tests

• make check passes locally (lint + mypy + pytest)
• New / changed behaviour has a test
• CHANGELOG.md updated under ## [Unreleased]

tests/test_explain_ranking.py::test_scope_filtered_candidate_does_not_carry_its_summary
— asserts the gate is still reported, the summary is "", the secret string
appears nowhere in the serialised result, and a retrievable candidate still
carries its summary. it fails on the previous code with the leaked text in the
assertion diff.

validation run:

python -m ruff check src tests
python -m mypy src
python -m pytest tests/test_explain_ranking.py tests/test_scoping.py \
                 tests/test_audit_scoping.py tests/test_context.py \
                 tests/test_capabilities.py -q

no ui files touched, so no screenshots.

[plind-junior]

Checked this against test and the diagnosis holds. Summaries was keyed off the pre-scope hits while scoped sat ten lines above it, so explain_ranking was the one read path returning text for artifacts the same viewer's kb.search had already dropped.

One followup, not for this PR: The report still exposes a filtered candidate's id and ranks. It's fine while scope is a relevance filter, but #608 makes the viewer no longer caller-declared, and that turns existence disclosure into the next question here.
LGTM!