fix(tools): match grep_search's include glob against the relative path

[Preciousuche]

Summary
grep_search matched the include glob against fp.name only (fnmatch.fnmatch(fp.name, include))
fp.name never contains a directory separator, so any path-qualified pattern (tests/.py, src/**/.ts) matched nothing, and grep_search silently reported "No matches" — indistinguishable to the caller from "this code does not exist"
Matched against fp.relative_to(base).as_posix() instead
fnmatch's * already spans / (fnmatch("src/a.py", ".py") is True), so every bare-filename pattern documented today keeps working exactly as before; path-qualified patterns now also work instead of silently matching nothing
Updated the include parameter's description, which previously documented only the bare-filename form
Fixes #1571
Test plan
Verified the tests catch the regression: stashed the source fix and reran — the path-qualified tests fail against the old code with the exact reported symptom ("No matches for 'def test_'"), while the bare-filename regression test correctly passed either way
Added test_grep_search_include.py (4 tests): the issue's exact reproduction (tests/.py now matches), the required non-regression (.py still matches at any depth), a src/**/.py case documenting fnmatch's actual non-recursive ** semantics, and a path-qualified pattern that correctly reports no matches when nothing qualifies
uv run pytest tests/test_tools -k "filesystem or grep" -q — 25 passed, 4 skipped
uv run ruff check / uv run mypy clean on changed files

[andreapn]

Thanks for the PR. #1571 was fixed by #1848. Matching only the relative path regresses bare globs with a literal prefix: fnmatch("tests/test_a.py", "test_*.py") and fnmatch("a/b/conftest.py", "conftest.py") are both False, so patterns that match nested files today would stop matching. The filename check has to stay. Closing in favour of #1848.