[chat-perf] layoutDurationMs regressed ~23% in multi-turn-user scenario

### Summary
A new regression was detected in the *multi-turn-user* scenario: `layoutDurationMs` increased by ~23% compared to the established baseline. This is outside the normal run-to-run noise and not previously tracked.

### Evidence
- **Current**: 220.05ms ±8.77ms
- **Baseline**: 179.53ms ±6.05ms
- **Delta**: +40.5ms (+22.6%)
- **Past 7 runs**: layoutDurationMs for multi-turn-user was stable in the 175–260ms range, with the last several runs at ~180ms. This jump to 220ms is a clear outlier.
- **p-value**: 0 (statistically significant)

#### Trend (last 7 runs):
- #224: 259.75ms (but this was a one-off, otherwise ~180ms)
- #223: 256.8ms
- #222: 207.84ms
- #221: 159.78ms
- #220: 197.32ms
- #219: 164.37ms
- #218: 193.47ms
- **Current**: 220.05ms

#### Suspect Commits
- The regression appears after commit `a036821` (feat(chat): introduce compact codicons and update related components), which touched many chat UI and CSS files, including those likely to affect layout and rendering.

### Suggested Action
- Investigate recent changes to chat UI components and CSS, especially those in `a036821`, for possible causes of increased layout duration in the multi-turn-user scenario.
- Consider profiling layout performance in this scenario to pinpoint the bottleneck.

_No open tracking issues or prior Slack threads cover this regression._

Start by reviewing the chat UI and CSS changes in commit a036821, then run or profile the multi-turn-user scenario while measuring layoutDurationMs. Compare the result with the stated baseline and inspect the changed components for the source of the regression. Done means the bottleneck is identified and the regression is tracked against the baseline.

Written by the indexing model from the issue text.