fix(search): restore zero-match probes on the rg engine after auto-multiline early-return

[teknium1]

Summary

Restores the #77011 zero-match steering probes (case-insensitive / hidden-file / literal-vs-regex) on the ripgrep engine — #77102's early return, added to skip the legacy line-oriented \n warning for rg, was also skipping the probe block.

Root cause: an integration regression between two individually-green PRs. #77011 attached the probes after the engine dispatch in _search_content; #77102 later added return result directly after the rg call so the grep-era line-oriented explanation wouldn't fire on an engine that now auto-multilines. That return bypassed the probes on the primary engine. Caught by #77001's rebased CI (its branch was the first to carry both features together).

Changes

• tools/file_operations.py (_search_content): probes run for BOTH engines; only the legacy line-oriented \n warning is rg-exempt (rg auto-enables --multiline; the grep fallback keeps the explanation).

Validation

Check	Result
Hermetic runner (zero-match+multipath, auto-multiline, file_operations, file_tools)	109/109 passed
Live E2E via real search_tool()	case probe fires; hidden probe fires; \n pattern still multiline-matches with mode note

Infographic

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 15b10d5}

all good!

[teknium1]

Hit this independently while triaging a red slice 8/8 on #77104 — same root cause, so I dropped my duplicate fix in favor of this one. Confirming the diagnosis from the other direction:

15:10  5797b50288  feat(search): zero-match probes and multi-path recovery   <- probe block added
15:10  e7aa06c3a6  feat(search): hidden/gitignored probe on zero-match results
15:13  1cefabc8af  feat(search): auto-enable multiline mode for newline patterns  <- added the early return

Three minutes apart. The later commit's return result orphaned the earlier one's block, so the entire zero-match steering tier was dead for every user with rg installed — reproduced on a pristine origin/main worktree: search_files('token_alpha', ...) against a file containing TOKEN_ALPHA returns a bare {"total_count": 0} with no hint. The 3 failing tests were the feature reporting its own absence.

One gap: this PR ships no tests, so a fourth commit can silently orphan the tier the same way. I have a regression class that fails on exactly that reintroduction — parametrized over both search engines, with the probe stubbed to a sentinel so it isolates the wiring rather than the probe's own rg dependency (worth noting: the probe shells out to rg by design, so a grep-only host gets no hints even when wiring is correct — a naive parity test asserting real hint text fails on the grep leg for that reason, not because of this bug).

Sabotage-verified against your fix: restoring the early return turns 4 tests red; never attaching the hint turns 5 red; attaching it when matches exist turns 2 red. 14/14 green on the fix.

Want me to push those tests onto this branch, or land them as a follow-up after this merges?