fix(desktop): transcript call headers stick flush to the top of the scroll area
Summary
In the side panel's Transcript tab, a stuck call header ("Today, 12:50 PM") sat 4px below the top of the scroll area, and a sliver of the lines scrolled under it showed above it.
The cause: the transcript's scroll box (ConversationContent) has Tailwind pt-1. A sticky top: 0 element sticks to the inner edge of its scroll container's padding, so those 4px were never covered.
The fix: the transcript's scroll box drops its top padding (pt-0, which wins over the registry's pt-1 through twMerge), and .plan-transcript-calls carries those 4px instead. A stuck header now sits flush against the top edge, and its opaque --desktop-well background covers everything above its text. The first call's resting position does not change: the before and after renders at scrollTop 0 are byte-identical.
The follow-newest and scroll-to-bottom logic (Conversation's followsNewest / scrollToBottom) is unchanged. Both read scrollHeight/scrollTop, which moving 4px of padding from the box to its first child leaves the same, and the existing plan-transcript.test.ts scroll tests pass.
Screenshots
Headless Chrome, rendering the real PlanTranscript with the built styles.css inside a .side-panel, scrolled 150px.
| Before | After |
|---|---|
 |  |
At rest (unchanged, byte-identical before and after):
Testing
./scripts/check.shexits 0.- No new test: jsdom does no layout, so where a sticky header lands cannot be asserted there. A test checking the class or the CSS value would be a change-detector test. The before/after Chrome renders above are the evidence.
- CI could not verify the Mac UI, and
./scripts/verify.shwas not run. This was a Linux cloud VM; LUKE-159 is the manual Mac pass.
š¤ Generated with Claude Code
