[HouMinXi]

Summary

Lite truncated tool results at a hardcoded 2000 characters. File reads and crash dumps arriving as tool payloads lost the middle of the content, and there was no supported way to raise the cap.

This adds lite.maxToolLength next to the existing compressToolResults toggle. Resolution order:

1. explicit option / step config / dashboard setting
2. OMNIROUTE_LITE_MAX_TOOL_LENGTH
3. 2000

Default stays 2000, so existing installs do not change. The truncation-allowlist idea stays a follow-up.

Related to #13178.
#13178 stays open.

Test plan

• compressToolResults honors an explicit cap below 2000
• a 1500-char payload is kept when the cap is 4000
• OMNIROUTE_LITE_MAX_TOOL_LENGTH is read when no option is passed
• an explicit option wins over the env fallback
• settings round-trip maxToolLength
• schema accepts an integer cap and rejects a string
• Lite engine schema exposes maxToolLength (default 2000, min 256)
• dashboard Save PUTs { compressToolResults, maxToolLength } when the operator set a cap
• dashboard Save omits maxToolLength when settings never stored one, and when the number input is cleared
• defect injection: hardcoding 2000 again fails the two new truncation tests; restoring the resolver passes

[HouMinXi]

Inline review of af4a921e90 found three real issues. They are fixed in 0e0d775964.

1. A pipeline step with maxToolLength: 10 (or NaN / Infinity) is still a number, so it hid a valid global cap of 8000 and fell through to env. A 3000-character tool result was truncated at env 400 instead of kept. Only an in-range integer now overrides the global cap.

2. PUT { lite: { compressToolResults: false } } replaced the whole lite JSON row, so a stored 8000 disappeared. Confirmed on a temp sqlite. Omit the key to keep the stored cap; send null to clear it.

3. Save treated an out-of-range number (100) like a cleared field and omitted it, which also wiped the stored cap. Save now refuses and does not PUT.

Copy that still said "over 2,000 characters" is updated. Lite Preview still posts a user message, so it cannot show tool truncation. That is existing preview scope, not this change.

Tests: node 65/65, vitest 15/15. Injected the three defects at the call sites; each test failed, then passed after restore.

Related to #13178. #13178 stays open.

[HouMinXi]

Follow-up on the last review of 0e0d775964.

The three runtime issues stayed fixed. Two leftovers were still real:

1. The dashboard still said "over 2,000 characters". Schema copy had changed, but the page overlays src/i18n/messages when that key exists, so operators never saw the schema string. All 66 catalogs now point at the Maximum tool-result length field / env.

2. The out-of-range Save test matched /save/i, which is the Save button. It now looks for "Failed to save configuration."

Lite Preview still posts a user message and does not send config.lite, so it cannot show tool truncation. That is existing preview scope.

Related to #13178. #13178 stays open.

[HouMinXi]

Third look at 4caf3a40a6.

The runtime cap, the settings merge, the dashboard copy, and the out-of-range Save error all still match the earlier follow-ups. No new defects.

Lite Preview still posts a user message and does not send config.lite, so it cannot show tool truncation. Same as before; not this change.

Related to #13178. #13178 stays open.

[HouMinXi]

Fourth look at 4caf3a40a6.

Same SHA as the third look. Runtime cap, settings merge, dashboard copy, and out-of-range Save still hold. No new defects.

Lite Preview still posts a user message and does not send config.lite. Same as before; not this change.

Related to #13178. #13178 stays open.

[HouMinXi]

Fifth look at 4caf3a40a6.

Same SHA as the third and fourth looks. Runtime cap, settings merge, dashboard copy, and out-of-range Save still hold. No new defects.

Lite Preview still posts a user message and does not send config.lite. Same as before; not this change.

Related to #13178. #13178 stays open.