Investigate 0.17.0 interaction p95 regressions

[benvinegar]

Context

The 0.17.0 release benchmark snapshot shows a mixed interaction-latency result versus 0.16.0:

• Scroll tick median improved: 3.35ms → 1.11ms (-66.9%)
• Scroll tick p95 regressed: 6.25ms → 13.27ms (+112.3%)
• Hunk nav median regressed: 68.17ms → 85.83ms (+25.9%)
• Hunk nav p95 regressed: 76.21ms → 94.68ms (+24.2%)

The scroll p95 is still below a 16.7ms frame budget in the release snapshot, but scroll/hunk-navigation latency are core interaction metrics and should not drift silently.

Notes

Possible contributing factors to isolate:

• OpenTUI upgrade from 0.1.89 to 0.4.2
• Bun benchmark/runtime change from 1.3.11 in the 0.16.0 snapshot to 1.3.14 in the 0.17.0 snapshot
• Review-stream/windowing boundary work during scroll ticks
• Selected-hunk reveal path work during ] navigation

The median scroll latency improving while p95 worsens suggests steady-state scrolling got faster but occasional ticks became heavier, likely around rendering/windowing boundaries or renderer flushes.

Suggested next steps

• Re-run 0.16.0 and 0.17.0 interaction benchmarks on the same Bun version.
• Isolate OpenTUI/Bun changes from app-level changes.
• Add focused profiling around measureScrollTickLatencies and measureKeyPressLatencies.
• If reproduced, optimize the heavy p95 path or add a more targeted regression guard.

[hiSandog]

A useful next step would be a minimal fixture for Investigate 0.17.0 interaction p95 regressions that includes one failing input and one nearby control case. That would make it clear whether the fix addresses the reported edge case without widening behavior unexpectedly. 3.35ms is a useful concrete anchor because it is named directly in the report.