fix(search): widen bounded keyword candidates for path filters

[Hiro-Chiba]

Refs #647

Summary

Mitigate silent keyword-search path misses beyond the initial 60-candidate window using bounded widening, with explicit incomplete-scan diagnostics.

This is not a claim of exhaustive path-scoped search. The issue remains open for a backend-side filtering/pagination solution.

Type

• Bug fix
• Feature
• Refactor
• Docs
• Test
• CI

Changes

• For keyword searches with a nonempty --path, widen the existing candidate request by a factor of four when path/role filtering leaves fewer than the requested results and the current response fills its window.
• Stop once enough results survive, the response is shorter than the requested window, or the candidate limit reaches 2,000. Replace each prefix response rather than concatenating duplicates.
• Preserve kind, language, revision, workspace/system scope, path normalization, ranking, and output limit across requests.
• Emit path_search_truncated in JSON/LLM and a stderr warning in text when the final 2,000-candidate window is full. This also applies to an empty filtered result.
• Leave unscoped and semantic searches on their existing single-request paths.
• Correct the help text to describe the existing hard path filter and document the bound.

Validation

• Five of the initial eight regression tests failed before the fix. The final expanded set has ten passing tests, covering a match at position 71, stopping conditions, role filtering, zero limit, query parameters, case/slash normalization, semantic ordering, and warnings in all three formats.
• Full CLI suite: 100 files passed, 1,822 tests passed and 3 skipped; parser smoke passed.
• Build, typecheck, lint (0 errors, 41 existing warnings), knip, flag-reference parity, and diff checks passed.
• Live backend 1.0.30: both previously empty partial-name/path queries now return the known target for output limits 10 and 1,000. A full-name control still returns the same target.
• The live requests completed in approximately 0.15–1.11 seconds in this local run; these are observations, not performance guarantees.

Limits and tradeoffs

• The released search endpoint has neither documented path filtering nor pagination. A nonmatching scope probe was ignored on backend 1.0.30, so this does not assume a new backend field.
• Prefix widening repeats work. With positive integer limits, the loop makes at most six requests and requests at most 2,000 candidates at once. The ceiling is a safety bound, not evidence of completeness.
• Matches after the final window can still be omitted. The diagnostic makes that limitation visible; narrowing the search term is the immediate workaround.
• Semantic path-search coverage is not changed. No new exit statuses, endpoints, dependencies, or persistent writes are introduced by the command.

All public repro names and paths are generic. No private source or graph identifiers are included.

Checklist

• Tests pass
• Smoke tests pass
• No raw errors introduced
• CLI output follows Ix format

Release checklist (if merging to main)

• ix-cli/package.json version bumped
• After merge: tag pushed (git tag vX.Y.Z && git push origin vX.Y.Z)
• If backend changes: ix-memory-layer tagged and released first (maintainers only — see Backend Development)
• If docker-compose.standalone.yml changed: verified curl | sh install works

Release versioning is left to the maintainer. No backend or Compose changes.