Fixes #4860: Cap problems output to prevent context overflow

[roomote]

Summary

This PR fixes issue #4860 by implementing a reasonable cap on the number of problems sent to the session context when users mention @problems.

Problem

When VSCode has a large number of problems (e.g., 60,000+ from a failed Scope: all 15 workspace projects
Lockfile is up to date, resolution step is skipped
Already up to date

╭───────────────────────────────────────────────╮
│ │
│ Update available! 10.8.1 → 10.12.1. │
│ Changelog: https://pnpm.io/v/10.12.1 │
│ To update, run: corepack use [email protected] │
│ │
╰───────────────────────────────────────────────╯

╭ Warning ─────────────────────────────────────────────────────────────────────╮
│ │
│ Ignored build scripts: @tailwindcss/oxide, @vscode/vsce-sign, │
│ better-sqlite3, core-js, esbuild, keytar, puppeteer-chromium-resolver, │
│ sharp. │
│ Run "pnpm approve-builds" to pick which dependencies should be allowed │
│ to run scripts. │
│ │
╰──────────────────────────────────────────────────────────────────────────────╯

. preinstall$ node scripts/bootstrap.mjs
. preinstall: Done
. install$ node scripts/bootstrap.mjs
. install: Done
. prepare$ husky
. prepare: Done
Done in 1.1s using pnpm v10.8.1 in a large monorepo), the extension would feed all problems into the session context without any limits. This could cause the session context to grow excessively (800k+ tokens), making sessions unresponsive, slow, and expensive.

Solution

• Added constant: Set to 100 problems as a reasonable limit
• Updated function: Added optional parameter with truncation logic
• Enhanced function: Now uses the new limit when processing @problems mentions
• Maintained backward compatibility: DiffViewProvider continues to show all problems for edit-specific diagnostics (no limit needed since these are directly related to current edits)
• Added comprehensive tests: Full test coverage for the new limiting functionality

Key Features

1. Smart truncation: When the limit is reached, shows a clear message indicating how many additional problems were truncated
2. Backward compatible: Existing functionality remains unchanged when no limit is specified
3. Context-aware: Edit-specific problems (from DiffViewProvider) are not limited since they're directly relevant to the current operation
4. Well-tested: Comprehensive test suite covering various scenarios including edge cases

Example Output

When there are more than 100 problems, users will see:

Testing

• ✅ All existing tests pass
• ✅ New comprehensive test suite added
• ✅ Type checking passes
• ✅ Linting passes

This change ensures that @problems mentions remain useful while preventing context overflow that could make sessions unusable.

---

Important

Cap problems output to 100 in session context to prevent overflow, with updates to diagnosticsToProblemsString() and comprehensive tests added.

• Behavior:
  • Cap problems sent to session context at 100 in getWorkspaceProblems() in index.ts to prevent overflow.
  • diagnosticsToProblemsString() in index.ts updated to handle optional maxProblems parameter for truncation.
  • DiffViewProvider in DiffViewProvider.ts continues to show all problems for edit-specific diagnostics.
• Testing:
  • Added tests in diagnostics.spec.ts to cover new limiting functionality, including edge cases.
• Misc:
  • Added MAX_PROBLEMS_IN_CONTEXT constant in index.ts for problem limit.
  • Improved truncation message to indicate number of truncated problems.

^{This description was created by for 82a4fa9. You can customize this summary. It will automatically update as commits are pushed.}

[daniel-lxs]

This PR limits problems by count rather than actual content size, which doesn't effectively prevent context overflow. Individual problems can vary greatly in size (long error messages, stack traces, lengthy source lines), so even 100 problems could still overwhelm the context if they contain large amounts of text.

Closing this PR so we can come up with a better solution. A better approach would be to limit by total character count or lines to ensure the context stays within bounds, tracking cumulative size while building the result and ensuring complete problems are included without truncation.