docs(grep_search): fix two incorrect gap notes contradicting the schema

Gap #7 claimed the schema marks all 10 params required 'for strict:true
mode', contradicting the doc body and the actual grep_search.ts (strict
disabled, required: [path, query] only). Gap #2 claimed the trade-offs
table still said 'post-filter only' when it already documents the dual
--ignore-file + post-filter strategy. Marked both resolved/corrected.

Author: alsterg

docs/grep_search-tool.md

@@ -189,7 +189,7 @@ Defaults: `isRegex=true`, `caseSensitive=false`, `wholeWord=false`, `fileTypes=n
 
 1. **Parser accepts `pattern` as a fallback for `query`.** Some models (notably when also using `sed`/`find_files`, which both use `pattern`) confabulate `pattern` as the parameter name for `grep_search`. The schema declares only `query` (keeping the API surface clean and consistent with `rag_search`/`lsp_search`/`git_search`), but the parser in [`NativeToolCallParser.ts`](../src/core/assistant-message/NativeToolCallParser.ts) silently falls back to `pattern` when `query` is missing — the same pattern used for [`fileTypes ?? file_pattern`](../src/core/assistant-message/NativeToolCallParser.ts:567). This is a parser-level resilience measure, not a schema alias.
 
-2. **Trade-offs table `.shofer/shoferignore` row is stale.** The table says "Post-filter via `ShoferIgnoreController`" but the current implementation also passes `--ignore-file <path-to-.shofer/shoferignore>` to ripgrep natively (see [`buildRipgrepArgs`](../src/core/tools/GrepSearchTool.ts:220-222)), so ignored files are excluded at the search level — not solely via post-filter. The post-filter in `execute()` is retained as a safety net. The doc should reflect the dual `.shofer/shoferignore` exclusion strategy (native rg flag + post-filter safety net).
+2. ~~Trade-offs table `.shofer/shoferignore` row is stale.~~ — ✅ resolved: the trade-offs table now reads "Native `--ignore-file` flag + post-filter safety net", reflecting the dual exclusion strategy (native rg `--ignore-file` in `buildRipgrepArgs` + the `execute()` post-filter backstop).
 
 3. **Ripgrep CLI Mapping code example is simplified.** The code block at §Ripgrep CLI Mapping omits the `--ignore-file` argument that `buildRipgrepArgs` adds when `.shofer/shoferignore` is loaded. It also omits the `directoryPath` → `resolvedPath` (absolute) conversion. These are acceptable simplifications for a conceptual mapping, but they differ from the actual source.
 
@@ -199,6 +199,6 @@ Defaults: `isRegex=true`, `caseSensitive=false`, `wholeWord=false`, `fileTypes=n
 
 6. **The `2× maxResults` fetch buffer is not documented.** The tool fetches `2 * maxResults * linesPerResult` worth of ripgrep lines to ensure the post-processing hit count can exceed `maxResults` and trigger the truncation flag. This implementation detail is not mentioned in the doc but matters for understanding why the tool might return fewer than `maxResults` results even when more exist — if all `maxResults` hits come from the first `maxResults * linesPerResult` lines, the buffer is never exceeded.
 
-7. **OpenAI schema `required` array marks all 10 params as required.** Although `fileTypes`, `excludePattern`, `isRegex`, etc. all have `null` defaults and are semantically optional, the schema declares them all `required` (lines 105-116 of `grep_search.ts`). This is intentional for `strict: true` mode but can confuse readers who see the doc's "Required" column showing ✅ for nullable params.
+7. ~~OpenAI schema `required` array marks all 10 params as required.~~ — **This gap note was wrong** (it described an older/imagined schema). The actual `grep_search.ts` disables `strict` and declares `required: ["path", "query"]` only; the optional params are genuinely optional, consistent with the body's "strict mode is intentionally disabled" and the Advisory Parameter Defaults Rule. No discrepancy.
 
 8. **Cross-reference to related tools not present.** The doc does not mention sibling search tools (`rag_search`, `git_search`) that share the same result-cap infrastructure via [`searchCap.ts`](../src/core/tools/helpers/searchCap.ts). Users choosing between `grep_search`, `rag_search`, and `git_search` would benefit from a brief comparison. The shared `formatTruncationHeader` ensures consistent header wording, which is an intentional design decision worth noting.