fix(chat): anchor the commit divider to the boundary, not to the end of the pane

[huhamhire]

The bug

The trailing commit divider rendered after everything in the timeline, so it was not marking a position — it was tracking the bottom. Every message, thinking step or queued run that arrived pushed it further down.

A boundary that moves is worse than no boundary: it reads as if the commit itself keeps happening later, and content that arrived after the new commit appears above the line that is supposed to mark it.

The fix

The boundary belongs immediately after the last run that reviewed the previous commit. Everything that arrives afterwards belongs below it — which is exactly what the divider is claiming. So it now anchors before whatever first followed that run, and falls back to the end only in the one case where nothing follows it yet, where the two positions coincide anyway.

The between-runs dividers were already correct (they anchor to a run) and are unchanged; the two kinds coexist without interfering.

Placement moved into computeCommitDividers, a pure function. It holds the only real reasoning in that block and was previously inlined in a component with no way to exercise it.

Verification

lint / typecheck / test / build pass. Placement was exercised against the pure function across the cases that matter — including the reported one:

Scenario	Result
Two runs, sha changed	divider before the newer run
Head advanced, nothing after the last run	trailing divider (the only remaining trailing case)
Head advanced, a message landed after	anchored before that message
More messages keep arriving	anchor unchanged — the reported bug
Head equals the reviewed sha	no divider
Runs predating the headSha field	ignored, no divider
A sha change between runs and an unreviewed head	both dividers, each in its own place

Not verified visually in the running app; the check was at the placement level.

🤖 Generated with Claude Code