# Issue 25396 reproduction

Environment: fs-35 Linux x86_64; real web dev server; Chrome 156, device pixel ratio 2, 1280x800 CSS viewport, 100% zoom. Source initially 6838e31b9c. Isolated state in worktree .t3, never live userdata.

1. Created /home/ubuntu/wt/issue-25396 from origin/main and ran vp install then vp run dev.
2. Paired the built-in Browser panel with the isolated server. Dev runner chose server 14281/web 6241.
3. Typed `Regular text and **bold text**` and sent it through the real composer. Provider replied with the same sample. Both user and assistant rendered strong elements computed font-weight 600.
4. Opened Settings → Beta, switched New design off, returned to thread. Both rendered strong elements still computed font-weight 600.
5. In the composer, selected a word and used Ctrl+B. Its strong element computed font-weight 700, while rendered message strong elements computed 600 before fix.
6. After the one-line CSS fix loaded, the two message strong elements and composer strong all computed 700. No message or provider protocol change was needed.

Note: preview_type inserts a literal string, so its insertion of Markdown did not trigger rich-text input rules. The Ctrl+B selection variant exercised rich-text bold. A transient blank splash resolved after initial Vite module loading; pairing succeeded.

The reporter uses Windows desktop. This Linux web reproduction establishes the shared stylesheet mismatch; native Windows font rasterization and shell are unverified.

Duplicate scan: paged all 1172 open issues, titles matched bold / markdown / font weight / semibold. No matching duplicate. Issue had no comments.

GitCafe issue 25396 corresponds to GitHub issue 25395, confirmed by exact title. GitHub issue 25396 is a different mobile composer report.

Verification after merging origin/main 0604547a3a into fix/issue-25396: vp run check:changed passed formatting and affected typechecks (web and scripts), no code/manifest changes requiring knip. No tests added for the purely visual bug.
