feat: provider-specific file reading limits (maxReadFileLine)

[roomote]

Related GitHub Issue

Closes: #11407

Description

This PR attempts to address Issue #11407 by adding a per-provider maxReadFileLine setting that allows users to override the default 2000-line limit when reading files. This helps users with slower local providers (e.g. CPU-based inference) avoid timeouts by reducing prompt size.

Key implementation details:

1. Provider settings schema (packages/types/src/provider-settings.ts): Added maxReadFileLine: z.number().int().min(1).optional() to baseProviderSettingsSchema, making it available across all provider types.

2. Tool description (src/core/prompts/tools/native-tools/read_file.ts): Updated createReadFileTool() to accept and use the provider's effective line limit in the tool description, so the model is told about the lower limit.

3. Tool chain (src/core/prompts/tools/native-tools/index.ts, src/core/task/build-tools.ts): Threaded maxReadFileLine from apiConfiguration through getNativeTools() and buildNativeToolsArrayWithRestrictions().

4. Execution enforcement (src/core/tools/ReadFileTool.ts): Both new and legacy execution paths clamp the effective limit using Math.min(requestedLimit, providerMaxLimit), so the provider's configured limit is always respected even if the model requests more.

5. @ mention file reads (src/core/mentions/index.ts, src/core/mentions/processUserContentMentions.ts, src/core/task/Task.ts): Threaded maxReadFileLine through parseMentions and processUserContentMentions to extractTextFromFileWithMetadata, so mention-based file reads also respect the setting.

6. UI (webview-ui/src/components/settings/MaxReadFileLineControl.tsx, webview-ui/src/components/settings/ApiOptions.tsx): Added a "Max file read lines" numeric input in the provider advanced settings section, following the same pattern as existing controls like rateLimitSeconds.

Test Procedure

• All existing ReadFileTool tests pass (33/33)
• All existing processUserContentMentions tests pass (10/10) after updating expectations for the new parameter
• All existing provider-settings tests pass (12/12)
• Full turbo lint and type-check pass across all 14 packages

Feedback and guidance are welcome.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue
• Scope: Changes are focused on the linked issue
• Self-Review: Self-reviewed
• Testing: Updated tests for new parameter
• Documentation Impact: No documentation updates required
• Contribution Guidelines: Read and agreed

Documentation Updates

• No documentation updates are required.

[roomote]

Rooviewer   See task

Reviewed the changes. The implementation is clean and correctly threads maxReadFileLine through all read paths (tool description, execution clamping, @ mentions, legacy path, UI). Two items to address:

• Add test coverage for the clamping logic in ReadFileTool.processTextFile (both slice and indentation modes)
• Consider refactoring parseMentions to use an options object instead of 9 positional parameters

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[roomote]

The clamping logic here (Math.min(requestedLimit, providerMaxReadFileLine)) is the core enforcement mechanism of this feature, but it has no test coverage. The test changes in this PR only add undefined to existing assertions to match the new parameter. There should be tests that verify: (1) when providerMaxReadFileLine=500 and the model requests limit=1000, the effective limit is 500, (2) when providerMaxReadFileLine is undefined, the existing DEFAULT_LINE_LIMIT behavior is preserved, and (3) the same clamping applies in both slice and indentation mode. Since processTextFile is private, these can be exercised through executeNew with a mocked task.apiConfiguration.

_{Fix it with Roo Code or mention @roomote and request a fix.}

[roomote]

parseMentions now has 9 positional parameters, which makes call sites fragile and hard to read (the tests that had to add undefined, // maxReadFileLine illustrate the problem). Its caller processUserContentMentions already uses a destructured options object. Consider refactoring parseMentions to accept an options object too, which would make adding future parameters straightforward and eliminate positional-ordering mistakes.

_{Fix it with Roo Code or mention @roomote and request a fix.}