Reproducer from #363: querying 'cli.rs' against a workspace with
several crates returns unrelated lib.rs files ahead of the actual
crates/forge_main/src/cli.rs. The exact basename match should be
ranked first, not fifth.

Cause (next commit): fuzzyScore in src/explore.zig:4948 gives
'special entry points' (lib.rs, main.go, index.ts) a +5%
multiplicative bonus regardless of whether the query asked for them.
Combined with shorter path normalization, that pushes the actual
cli.rs match below the lib.rs decoys.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Querying 'cli.rs' against a multi-crate workspace returned four
unrelated lib.rs files ahead of the actual cli.rs. Two compounding
factors:

1. fuzzyScore gives lib.rs / main.go / index.ts a +5%
   special-entry-point bonus — applied regardless of whether the
   query asked for those names.
2. Path-length normalization (best_score / sqrt(path.len)) rewards
   shorter paths. lib.rs files with shorter parent paths beat the
   actual cli.rs match on length even when the cli.rs alignment
   was strictly better at the basename level.

Fix: when the query case-insensitively equals the filename, apply
a 4x multiplier so the exact match dominates length normalization
and the special-entry-point bonus on competing files. This mirrors
fzf-style "exact match always wins" behavior.

Companion test in src/tests.zig from the previous commit
(issue-363b: fuzzyFindFiles ranks exact basename match above
unrelated lib.rs) now passes; all 424 tests green.

Closes #363 (item b: fuzzy filename ranking).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Document the version sync fix, #363b basename ranking fix, and
honestly flag #363a as not-reproducible-in-isolation. Note that
#357 (received keys diagnostic, shipped in 0.2.5792) already
addresses #363c.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

User reported that codedb_search query='pub struct ForgeApp'
returned only architecture.md, missing the canonical Rust source
file at crates/forge_app/src/app.rs:47 even though the phrase is
a contiguous substring there.

A Sonnet 4.6 agent driving the live MCP narrowed the bug down to
single-token queries against repos where doc files mention the
identifier many times. Tier 0 of searchContent (explore.zig:1511)
iterates word-index hits in posting-list (insertion) order and
appends each (path, line) hit to result_list. When the gate
`word_hits.len <= max_results * 2` holds, Tier 0 runs; once
result_list reaches max_results it returns. Doc files indexed
earlier than source files dominate the posting list, fill the
quota, and source-file hits at the end never make it in.

Fix: in Tier 0, track hits per path and cap them at
max(1, max_results / 5). For the default max_results=50 each file
contributes at most 10 hits, leaving room for at least 5 distinct
files in the result set. For small max_results the cap floors at
1 so diversity is preserved aggressively.

This is a minimal change — Tier 0 still runs first, the gate is
unchanged, and the cap doesn't affect Tier 1+ paths. The display
layer in mcp.zig already caps per-file output at 5 so user-visible
behavior for high-density single-file matches is unchanged.

Companion failing test in src/tests.zig from the previous commit
(issue-363a: searchContent surfaces source-file matches even when
doc files dominate the word index) now passes; all 425 tests green.

Closes #363 (item a: literal search recall).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Promote the release notes from "two fixes + #363a not reproduced"
to "all of #363 resolved" now that the Tier 0 quota saturation
fix landed. Restore the missing 0.2.5792 section header.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Three reliability improvements landing as the rewritten phase 1 of #356
(Agent Context Planner framing dropped — codedb stays a tool, agent
stays in charge of composition):

1. codedb_query: partial results when a step fails. Pipeline previously
   bailed on the first error and discarded successful prior-step output.
   New behavior: the prior-step output is preserved and a structured
   "--- partial ---" tail names the failing step + reason. Callers can
   recover from a single bad step instead of starting over.

2. codedb_outline: fuzzy path fallback. A non-indexed path used to
   return a bare 'error: file not indexed: <path>'. Now appends up to
   3 fuzzy-matched indexed paths under a 'did you mean:' header, so an
   agent that mistypes a path can self-correct without a separate
   codedb_find round-trip.

3. codedb_query: received-keys diagnostic on missing-arg errors.
   Mirrors the #357 codedb_bundle diagnostic. When a step fails with
   e.g. 'search needs query' but the step actually has a 'q' key
   instead, callers see 'received keys: [op, q]' so they can tell
   whether codedb dropped the field or the client sent it under the
   wrong name.

Implementation:
  - New helper appendFuzzyPathSuggestions in mcp.zig — used in
    handleOutline's "file not indexed" path.
  - New helper finishQueryWithFailure in mcp.zig — emits both the
    received-keys diagnostic and the partial-results tail. Wired
    into the missing-arg error sites for op-detection, find, search,
    word, and symbol pipeline ops.
  - Other error paths in handleQuery (transient OOM, "needs prior
    step" for non-leading ops) keep the previous behavior; they don't
    surface received-keys but they will get partial-results coverage
    in a follow-up.

Tests: src/tests.zig adds three issue-356 cases (one per item) which
fail on main and pass with this commit. All 428 tests green.

Closes parts of #356 (phase 1 reliability scope).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Promote release notes to cover #356 phase 1 reliability work
(partial results, fuzzy path fallback, received-keys diagnostic
for codedb_query) alongside the original #363 fixes. Re-add the
0.2.5792 section header.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>