feat(tools): add KnowledgeIndex for progressive disclosure over reference knowledge

[pdebjyot]

What & why

Closes #395. Extends the progressive-disclosure work from #343 to a second kind
of oversized input: reference knowledge that lives outside the trace — the
catalog of tools/skills the agent could have used, API specs, policy documents.

That corpus overflows the judge for the same reason a large trajectory does
(#342), and inlining all of it degrades accuracy even when it fits
(lost-in-the-middle, position bias). A Session also can't answer capability
questions — it only holds what a run actually invoked, so a rubric like "was
there a tool that would have satisfied this request?" needs the full catalog,
which is a standalone knowledge source rather than a slice of the trace.

What's in the PR

1. refactor(tools) — extract shared helpers (_progressive.py).
TraceIndex's paging, windowing, and budget-bounded search move into a shared
module so the new index reuses identical behavior and the two can't drift. No
observable change to TraceIndex (overview()/get_span/search_spans now
delegate; local _window/_preview/constants removed). Existing TraceIndex
tests pass unchanged.

2. feat(tools) — KnowledgeIndex. Same list / get / search shape over an
arbitrary keyed corpus ({key: text}, KnowledgeEntry iterable, or pairs), with
two modes:

from strands_evals.tools.knowledge_index import KnowledgeIndex

index = KnowledgeIndex(tool_catalog)

# Mode A — retrieve-then-inject (default; deterministic, one LLM call)
knowledge_block = index.render(keys=plan_tool_names)   # bounded <Knowledge> block
judged_output = f"{agent_answer}\n{knowledge_block}"

# Mode B — agentic discovery (reserve for open-ended lookup)
prompt_section, tools = index.for_judge()              # overview + list/get/search

• Mode A (render) — the metric selects the trace-relevant keys and injects
  only that bounded slice. Use it whenever the keys are derivable from the trace.
• Mode B (for_judge) — overview + list_entries/get_entry/search_entries
  tools; reserve for when the needed entry can't be predetermined.

Both honor the same max_read_chars bound and case-insensitive literal-or-regex
search (line-anchored ^/$) as TraceIndex. Composes with OutputEvaluator
(caller-controlled output), not TrajectoryEvaluator.

Show it works

Offline, on a 201-entry tool catalog (~85 KB) with the one decisive tool buried
mid-catalog:

path	chars into the prompt	decisive tool available?
inline full catalog	84,730	yes, but overflows / judge skims
Mode B overview	8,054 (10.5× smaller, paged)	found via search_entries("escalate")
Mode A render(keys)	318 (266× smaller)	yes, exact slice

tests_integ/test_knowledge_index_judge_reliability.py is a Bedrock A/B (skips
without creds): the agent declines a request claiming no capability exists;
inline vs render vs explore are scored on a grounded case (no such tool →
declining is correct) and a fabricated case (tool exists mid-catalog → declining
is wrong). Both progressive modes must separate the two.

Tests / checks

• 23 new unit tests for KnowledgeIndex (paging, get/missing key, windowing,
  literal/regex/anchored/budget search, render slice/dedupe/bounds, input
  coercion, validation). Full suite: 1793 passed.
• ruff check and mypy -p src clean.
• No behavior change to TraceIndex — its tests pass as-is.

Builds on #343; independent of the #342 could-not-evaluate status work.