fix(session_search): cap per-message content on the read shape

[MrSimonC]

What does this PR do?

Caps per-message content on the session_search read shape (_read_session). #69334 added max_content_len to _shape_message and used it for discovery bookends (1200) and scroll windows (4000), but the read path still shaped rows with no cap, so a single archived tool result stored as a message could come back whole. I hit a read that returned 74K chars in one tool result and took a request from ~50K to ~89K tokens in a step, which kills a session on a 64K local slot.

This uses the same mechanism with a 2000-char cap and the same content_truncated / original_content_chars metadata, so the agent can scroll for detail if it needs it. Bounding message count (head 20 / tail 10) on its own isn't enough when each message is unbounded.

Related Issue

Fixes #114344

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• tools/session_search_tool.py: add _READ_MAX_CONTENT = 2000 and pass it as max_content_len in _read_session. One call site, no schema or output-shape change beyond the existing truncation metadata.
• tests/tools/test_session_search.py: add TestReadShape::test_read_caps_oversized_message_content - an 80K-char message on a 3-message session must come back capped with original_content_chars == 80000 and the whole read under 5K chars.

How to Test

1. pytest tests/tools/test_session_search.py -q - 68 pass (67 existing + 1 new).
2. Negative control: revert the _read_session call site to _shape_message(m) and the new test fails.
3. Manually: take a session with a large tool result in its first 20 or last 10 messages, call session_search(session_id=<id>) from a fresh session, and check the big message now carries content_truncated: true.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate (fix(tools): filter compaction summaries from session_search bookends and cap content length #43184/fix(search): keep compaction summaries and megabyte messages out of discovery bookends #69334 covered discover and scroll; Page session_search read-mode transcripts #61701 paged the read query but only bounded count)
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass - ran tests/tools/test_session_search.py (68 pass); I haven't run the full suite locally
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS 26.6, Python 3.11, local llama.cpp endpoint. I've run this same change as a local patch since August.

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — N/A, the inline comment explains the cap
• I've updated cli-config.yaml.example if I added/changed config keys — N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — N/A, pure Python string slicing

[teknium1]

Thanks @MrSimonC. Your change was salvaged into #114901 with your authorship preserved (cherry-picked); #114901 — fix(session_search): read shape and title-match entries cap per-message content like FTS hits (#114344, salvage #114349) — is now merged on main at 77da057c5e73, closing issues #114344. Closing this PR in favour of the landed change; if you see a case it does not cover, please open a fresh issue with the repro and tag it.