fix(ripgrep): return partial results instead of failing when output exceeds maxBuffer

[Yuki-zik]

Summary

On large repositories, ripgrep's stdout could exceed the default 200 KB maxBuffer. When that happened, ripgrep.search killed the process and rejected the entire promise, so the TaskVision tree showed zero todos — the symptom reported in the issue.

This PR raises the default buffer and, more importantly, degrades gracefully when the limit is still exceeded so the tree keeps populating.

Changes

• package.json — Raise the default taskvision.ripgrep.ripgrepMaxBuffer from 200 to 20480 (20 MB).
• package.nls.json / package.nls.zh-cn.json — Update the setting description to note the new 20 MB default and that it can be raised further; TaskVision now shows partial results and warns instead of failing.
• src/ripgrep.js — On buffer overflow, set a truncated flag, stop the process (SIGINT), and in the close handler resolve with the partial formatResults(...) (array carries truncated + maxBuffer markers) instead of rejecting. A clear warning is logged to options.outputChannel. The genuine SIGINT interrupted path and non-zero exit-code handling are preserved.
• src/extension.js — search() detects matches.truncated and shows a one-time, non-fatal warning advising the user to raise taskvision.ripgrep.ripgrepMaxBuffer (reuses the existing Open Settings pattern). The one-time flag resets at the start of each rebuild().
• test/ripgrep.tests.js — New regression test asserting that a buffer overflow resolves with partial results (truncated flag set) rather than rejecting.

Verification

• npm test — 120 passing (119 baseline + 1 new truncation test; the existing ripgrep.kill forwards SIGINT interrupted test still passes, confirming no regression).
• npm run webpack — build succeeded.

Fixes #4

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com