Skip layout for rejected transcript render results

[trissim]

Fix

Rejected transcript render results no longer invalidate page geometry. TranscriptFragment.hold_lines reports whether it retained rows for its current block source. TranscriptLinesRenderTask.hold returns that result after its existing width/theme/link-context check. TranscriptPageView._publish consumes every result and returns before opening a history change when none were retained. A history change itself keeps the reader and can interrupt an unfinished layout, so suppressing only range_changed inside that scope was insufficient.

No new state, cache, debounce, budget, worker, CSS or Textual change. Genuine width measurement, range/filter changes and explicit detail changes retain their existing invalidation paths. The live meter now includes mouse input, not just keys/wheel.

Owner and consumer evidence

Before: both retention methods returned None, including rejection, so _publish always invalidated geometry.
After: source acceptance is decided once by TranscriptFragment.hold_lines; render applicability is decided once by TranscriptLinesRenderTask.current_for; the page consumes their result instead of inventing another validity check.

Complete production search over Toad/Core/Textual:

rg -n '\.hold_lines\(|\bhold_lines\b|task\.hold\(|request\.hold\(' src /home/ts/wt/core-model-info/src /home/ts/wt/textual-main/src

Two direct fragment consumers: TranscriptLinesRenderTask.hold forwards acceptance; TranscriptLinesRenderTask.show owns an explicit shown-state change and keeps its independent invalidation even if prepared rows are rejected. Two task consumers: _publish now uses acceptance; LineHistory.prepare_fragments already loops against canonical fragment.lines_for(width, theme) and has no layout side effect to suppress. No other production consumers found.

The same existing refactor-audit parser inspected 282 Toad / 321 Core / 250 Textual / 38 ACP / 105 Pydantic modules before/after, with zero parse omissions. Evidence: /home/ts/.cache/agent-scratch/toad-sidebar-drag-9579/render-owners-{before,after}.txt. AST does not prove dynamic binding; the live run follows.

Verification

• Imports and whitespace pass. No automated tests edited or run (project instruction).
• Actual installed f448b33/Core f1b33c10 versus this source overlay: both left/right continuous physical drags completed with real handle capture, no text selection, changing widths, release and normal close. Same installed dependencies, one frontend at a time on isolated display77; no build/provider input/replay.
• Candidate hold returned False for 242 left / 100 right publication results, and True exactly when fragment retention returned True. Both production owners were exercised through the application.
• This does not fix drag responsiveness. Input-to-paint p95 remains 2651ms left / 3652ms right (baseline 2747 / 2902ms); no demonstrated latency improvement. Long frame work remains dominated by repeated Screen._finish_stepped_layout callbacks. The exact frame/latency figures and scenario limits are in the single series row in docs/performance/scroll-series.md; no fixed scrolling acceptance is claimed.
• Imports, whitespace and whole-change debt ratchet pass. Final parser output: render-owners-final.txt, same module totals and zero parse omissions. Source replacement rejection is source-verified but was not forced with fabricated data.
• Earlier drag observation also found the separate stale-detail-action crash; UX owns that repair, not this change.
• Not merged or installed. No 16ms claim.

[trissim]

Owner: toad-close-lifecycle (existing divider/render-rejection implementation and verification owner); Codex integrates/installs. Full diff read against current main e8716b9: still needed, not superseded. Main still opens preserve_history/range_changed for rejected render results; this branch deletes that unnecessary layout work by consuming the retention owner result. Remaining: current-main integration and installed rejection/valid-render behavior. Existing diagnostic explicitly shows drag latency still broken; no 16 ms or performance-success claim.