VS Code parity (Tier 2b of #699): GTK UI font stack (blocked on quadraui#624) + panel separator borders

[JDonaghy]

Tier 2b of #699 (VS Code visual-parity audit) — the half of the original #701 that
cannot start yet. Split out so Tier 2a (#701, line-number and breadcrumb dimming)
could be dispatched immediately instead of waiting behind this.

Two items, blocked for two different reasons.

1. UI font stack — BLOCKED on JDonaghy/quadraui#624

UI_FONT_FAMILY = "Segoe UI, Ubuntu, Droid Sans, Sans" (src/gtk/mod.rs:64). On
Linux neither Segoe UI nor Droid Sans resolves, so it falls through to generic Sans
(DejaVu Sans) — wider, with a taller x-height, than what VS Code lands on at the same
nominal size. Put the real system UI font first (system-ui / Cantarell / Ubuntu)
ahead of the generic fallback. Default ui_font_size = 10 pt
(src/core/settings.rs:728) ≈ 13.3 px at 96 dpi against VS Code's 13 px — check
whether the size still needs a nudge once the family is right, rather than changing
both blind.

Do not start this before quadraui#624 lands. vimcode feeds UI_FONT_FAMILY into
GtkBackend::set_ui_font (src/gtk/mod.rs:2144), and at the currently pinned rev that
field is read by exactly two primitives — draw_dialog and draw_rich_text_popup.
Every other chrome surface (tab bar, breadcrumb, file tree, status bar, menu bar)
paints with the shared editor Pango layout. Changing the family today would alter
dialogs and popups and nothing else, i.e. it would look done and change none of the
surfaces this epic is about — the same failure shape as #700 item 1, which shipped as
a no-op for exactly this class of reason.

Per the Platform-Neutrality Rule the workaround (building our own Pango layout in
src/gtk/) is not an option.

This item is inherently visual — attach a before/after screenshot to the PR, in
addition to whatever assertion is practical.

2. Panel separator borders — NEEDS SCOPING FIRST

VS Code Dark Modern draws a 1 px #2B2B2B line between activity bar / sidebar /
editor. vimcode's panes share a background value and butt together, so the sidebar
reads as part of the editor.

Before writing any code, establish where the line can be painted. vimcode composes
these panes itself, so a naive fix is a cr.rectangle in src/gtk/mod.rs — which the
Platform-Neutrality Rule forbids, and which would leave TUI unfixed. Determine whether
quadraui exposes a shared seam/border facility (Split/SplitLayout and the
border_fg family in quadraui/src/theme.rs are the places to look). If it does, add
the vimcode theme token and route through it. If it does not, do not implement —
file a quadraui issue and link it here, the same path #623/#624/#625 took.

Report which of the two it turned out to be in the PR or a comment, even if the answer
is "filed a quadraui issue and stopped".

Acceptance

GtkDriver (src/gtk/testing.rs), asserting on rendered pixels:

• item 1: chrome glyph extents change when UI_FONT_FAMILY changes, on a surface
  that is not a dialog — a tab label or status-bar segment. This assertion is
  impossible to satisfy before quadraui#624; that is the point of it.
• item 2: the pixel column between sidebar and editor is the border colour, not
  the sidebar background.

Depends on

• GtkBackend::ui_font is honoured by only draw_dialog and draw_rich_text_popup — all other chrome paints with the editor font (blocks vimcode#700 item 3 and vimcode#701 item 1) quadraui#624 — hard blocker for item 1.
• Item 2 blocks on its own scoping question, not on #603: #595 Stage 4 — wire remaining TuiShellApp::handle key dispatch (dialog/palette/completion/context-menu + #318 Alt-reveal shim) #624.

Files

• src/gtk/mod.rs
• src/render.rs
• src/core/settings.rs
• src/gtk/testing.rs (tests)

[JDonaghy]

Coordinator Assignment

Machine: precision
Repo: vimcode
Files: (unspecified)
Do not touch: (nothing else in flight)

Briefing

Issue #704: VS Code parity (Tier 2b of #699): GTK UI font stack (blocked on quadraui#624) + panel separator borders

Tier 2b of #699 (VS Code visual-parity audit) — the half of the original #701 that
cannot start yet. Split out so Tier 2a (#701, line-number and breadcrumb dimming)
could be dispatched immediately instead of waiting behind this.

Two items, blocked for two different reasons.

1. UI font stack — BLOCKED on JDonaghy/quadraui#624

UI_FONT_FAMILY = "Segoe UI, Ubuntu, Droid Sans, Sans" (src/gtk/mod.rs:64). On
Linux neither Segoe UI nor Droid Sans resolves, so it falls through to generic Sans
(DejaVu Sans) — wider, with a taller x-height, than what VS Code lands on at the same
nominal size. Put the real system UI font first (system-ui / Cantarell / Ubuntu)
ahead of the generic fallback. Default ui_font_size = 10 pt
(src/core/settings.rs:728) ≈ 13.3 px at 96 dpi against VS Code's 13 px — check
whether the size still needs a nudge once the family is right, rather than changing
both blind.

Do not start this before quadraui#624 lands. vimcode feeds UI_FONT_FAMILY into
GtkBackend::set_ui_font (src/gtk/mod.rs:2144), and at the currently pinned rev that
field is read by exactly two primitives — draw_dialog and draw_rich_text_popup.
Every other chrome surface (tab bar, breadcrumb, file tree, status bar, menu bar)
paints with the shared editor Pango layout. Changing the family today would alter
dialogs and popups and nothing else, i.e. it would look done and change none of the
surfaces this epic is about — the same failure shape as #700 item 1, which shipped as
a no-op for exactly this class of reason.

Per the Platform-Neutrality Rule the workaround (building our own Pango layout in
src/gtk/) is not an option.

This item is inherently visual — attach a before/after screenshot to the PR, in
addition to whatever assertion is practical.

2. Panel separator borders — NEEDS SCOPING FIRST

VS Code Dark Modern draws a 1 px #2B2B2B line between activity bar / sidebar /
editor. vimcode's panes share a background value and butt together, so the sidebar
reads as part of the editor.

Before writing any code, establish where the line can be painted. vimcode composes
these panes itself, so a naive fix is a cr.rectangle in src/gtk/mod.rs — which the
Platform-Neutrality Rule forbids, and which would leave TUI unfixed. Determine whether
quadraui exposes a shared seam/border facility (Split/SplitLayout and the
border_fg family in quadraui/src/theme.rs are the places to look). If it does, add
the vimcode theme token and route through it. If it does not, do not implement —
file a quadraui issue and link it here, the same path #623/#624/#625 took.

Report which of the two it turned out to be in the PR or a comment, even if the answer
is "filed a quadraui issue and stopped".

Acceptance

GtkDriver (src/gtk/testing.rs), asserting on rendered pixels:

• item 1: chrome glyph extents change when UI_FONT_FAMILY changes, on a surface
  that is not a dialog — a tab label or status-bar segment. This assertion is
  impossible to satisfy before quadraui#624; that is the point of it.
• item 2: the pixel column between sidebar and editor is the border colour, not
  the sidebar background.

Depends on

• GtkBackend::ui_font is honoured by only draw_dialog and draw_rich_text_popup — all other chrome paints with the editor font (blocks vimcode#700 item 3 and vimcode#701 item 1) quadraui#624 — hard blocker for item 1.
• Item 2 blocks on its own scoping question, not on #603: #595 Stage 4 — wire remaining TuiShellApp::handle key dispatch (dialog/palette/completion/context-menu + #318 Alt-reveal shim) #624.

Files

• src/gtk/mod.rs
• src/render.rs
• src/core/settings.rs
• src/gtk/testing.rs (tests)

[JDonaghy]

Coordinator: Assignment Complete

Machine: precision
Status: done
Exit code: 0
Duration: 13m 18s
Log: /home/john/.coord/logs/810ec9a59326.log

[JDonaghy]

⏱ Needs attention

Machine: dellserver
Assignment: e0e33ac783e1
Issue: #704
Reason: Running too long

Running 22.7m, past the 20m threshold for type='smoke'.

Detection + surfacing only — nothing was killed or reassigned. A human should take a look; use coord log <id> to see what it's doing, or coord retry/coord stop to intervene.

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: 24m 46s
Log: /home/john/.coord/logs/e0e33ac783e1.log

[JDonaghy]

Coordinator: Assignment Complete

Machine: dellserver
Status: done
Exit code: 0
Duration: —

Summary

Verdict: approve

Review findings

Blocking findings

None.

Non-blocking concerns

• src/gtk/testing.rs (new test tab_label_width_tracks_ui_font_size_not_editor_font_size, ~line 1575): I independently verified (by reading the pinned quadraui rev 097eb5f4 — quadraui/src/gtk/backend.rs::draw_tab_bar_icons/set_ui_font, and confirming src/gtk/mod.rs's backend.set_ui_font(&UI_FONT()) call site and the draw_tab_bar_icons call site are both unchanged by this diff) that the ui_font_size → tab-bar-glyph-width pipeline this test exercises was already live on develop before this PR, wired by the prior Complete Tier 1 of #699: bump the quadraui pin and land #700 items 1, 3 and 5 for real #705/quadraui#624 PR (e8124c3). That means reverting only this PR's actual code change (the one-line UI_FONT_FAMILY reorder) leaves the new test green — it proves the pipeline reaches a previously-untested surface (tab bar), but it does not pin down this diff's change the way CLAUDE.md's "state that the new test was observed RED against unfixed develop" rule asks for. The commit message gives a thoughtful rationale for why family can't be varied directly (no runtime setting; family+size travel as one Pango string; a literal font-swap test would also be font-availability-dependent across machines/CI) but never states an explicit RED-verification, and, per my check, this particular assertion structurally can't be made RED by reverting this PR's diff alone. Recommend one added sentence in the PR clarifying that this test's RED case is "the quadraui#624 wiring missing" rather than "this diff's family string reverted," so nobody later mistakes it for pinning the visual family fix itself.
• Issue VS Code parity (Tier 2b of #699): GTK UI font stack (blocked on quadraui#624) + panel separator borders #704 explicitly says, for item 1: "This item is inherently visual — attach a before/after screenshot to the PR." I found no screenshot/image committed in fc10f01, and the commit message (which is likely the PR body, since it's the branch's only commit) makes no mention of one. I don't have gh access to check the actual PR page for an attached image, so I can't confirm this is missing — just flagging that it isn't visible from the diff/commit I could review, and asking the coordinator (who has gh) to confirm the screenshot is actually attached to PR #704: VS Code parity (Tier 2b of #699): GTK UI font stack (blocked on quadraui#624) + panel separator borders #709 before merge.
• Minor test-robustness note (not verified, since I was told not to run the test suite): tab_label_width_tracks_ui_font_size_not_editor_font_size uses ui_font_size = 28 in a 1400×900 window with three tabs. If the tab-bar rasteriser truncates/ellipsizes long labels under tight width (unlike the breadcrumb path this pattern was copied from), find_bounds("alpha703") could behave differently than expected at that size. The precedent test (breadcrumb_text_width_tracks_ui_font_size_not_editor_font_size) uses the identical 8/28 pair successfully, so this is low-risk, just noting it wasn't independently re-verified here.

Nits

None.

---

Summary of what I checked

Item 1 (UI font stack, src/gtk/mod.rs): The one-line UI_FONT_FAMILY reorder ("Cantarell, Ubuntu, Segoe UI, Droid Sans, Sans") is exactly the fix the issue asked for — real Linux desktop UI fonts (Cantarell for GNOME, Ubuntu for Ubuntu/Unity) ahead of the Windows/legacy names, Sans kept as the final catch-all. I verified the claimed unblocking condition is real: quadraui's pinned rev (097eb5f4, already the repo's current pin as of e8124c3, landed before this PR) does route draw_tab_bar_icons, draw_status_bar, draw_tree, and draw_menu_bar through self.ui_font (quadraui#624), and vimcode's App::render_content already calls backend.set_ui_font(&UI_FONT()) every frame — so changing UI_FONT_FAMILY today does reach non-dialog chrome, not just dialogs, as the issue required before allowing this change. ui_font_size was correctly left untouched, with a reasoned justification (the ~2% size delta vs. VS Code is dwarfed by the family-driven metric change, and changing both at once would make it impossible to attribute either effect) — consistent with the issue's explicit instruction not to change both blind.

Item 2 (panel separator borders): No vimcode code changes, which is correct per the Platform-Neutrality Rule (no cr.rectangle patch in src/gtk/mod.rs). The commit message reports the scoping outcome: quadraui's AppShell::render/AppShellLayout.divider_bounds already paints a sidebar/editor divider on both backends, but its color is hardcoded (Color::rgb(100, 100, 110)) with no themed parameter or Backend::theme() read-back — I confirmed this directly in the pinned quadraui checkout (quadraui/src/compose/app_shell.rs:662-663), and confirmed vimcode's src/gtk/mod.rs does route its shell layout through quadraui::AppShellLayout/AppShellEvent, so the facility examined is the one vimcode's sidebar/editor composition actually uses. This is a legitimate "file a quadraui issue and stop" outcome per the issue's own decision tree, correctly not implemented in vimcode. The worker flagged it for the coordinator to file on JDonaghy/quadraui since worker sessions don't run gh — that hand-off itself is fine, just make sure it actually gets filed and linked back, since the issue asked for it to be "linked here."

General: No CLAUDE.md changes (coordinator-owned doc untouched). No security surface. No scope creep — src/render.rs and src/core/settings.rs (listed as candidate files) are untouched, correctly, since neither item ended up needing them. The added test follows established codebase conventions (mirrors the pre-existing breadcrumb_text_width_tracks_ui_font_size_not_editor_font_size pattern almost exactly) and asserts on real rendered pixel bounds (find_bounds widths), not on internal state — satisfying the "rendered output, not state" rule.

[JDonaghy]

Review Complete — ✅ Approved

Reviewer findings could not be posted directly to PR #709 (gh pr review was rejected — likely a self-review restriction). Findings are reproduced here.

Note: a completion comment was posted earlier but findings could not be extracted at that time. These are the retroactive findings.

Blocking findings

None.

Non-blocking concerns

• src/gtk/testing.rs (new test tab_label_width_tracks_ui_font_size_not_editor_font_size, ~line 1575): I independently verified (by reading the pinned quadraui rev 097eb5f4 — quadraui/src/gtk/backend.rs::draw_tab_bar_icons/set_ui_font, and confirming src/gtk/mod.rs's backend.set_ui_font(&UI_FONT()) call site and the draw_tab_bar_icons call site are both unchanged by this diff) that the ui_font_size → tab-bar-glyph-width pipeline this test exercises was already live on develop before this PR, wired by the prior Complete Tier 1 of #699: bump the quadraui pin and land #700 items 1, 3 and 5 for real #705/quadraui#624 PR (e8124c3). That means reverting only this PR's actual code change (the one-line UI_FONT_FAMILY reorder) leaves the new test green — it proves the pipeline reaches a previously-untested surface (tab bar), but it does not pin down this diff's change the way CLAUDE.md's "state that the new test was observed RED against unfixed develop" rule asks for. The commit message gives a thoughtful rationale for why family can't be varied directly (no runtime setting; family+size travel as one Pango string; a literal font-swap test would also be font-availability-dependent across machines/CI) but never states an explicit RED-verification, and, per my check, this particular assertion structurally can't be made RED by reverting this PR's diff alone. Recommend one added sentence in the PR clarifying that this test's RED case is "the quadraui#624 wiring missing" rather than "this diff's family string reverted," so nobody later mistakes it for pinning the visual family fix itself.
• Issue VS Code parity (Tier 2b of #699): GTK UI font stack (blocked on quadraui#624) + panel separator borders #704 explicitly says, for item 1: "This item is inherently visual — attach a before/after screenshot to the PR." I found no screenshot/image committed in fc10f01, and the commit message (which is likely the PR body, since it's the branch's only commit) makes no mention of one. I don't have gh access to check the actual PR page for an attached image, so I can't confirm this is missing — just flagging that it isn't visible from the diff/commit I could review, and asking the coordinator (who has gh) to confirm the screenshot is actually attached to PR #704: VS Code parity (Tier 2b of #699): GTK UI font stack (blocked on quadraui#624) + panel separator borders #709 before merge.
• Minor test-robustness note (not verified, since I was told not to run the test suite): tab_label_width_tracks_ui_font_size_not_editor_font_size uses ui_font_size = 28 in a 1400×900 window with three tabs. If the tab-bar rasteriser truncates/ellipsizes long labels under tight width (unlike the breadcrumb path this pattern was copied from), find_bounds("alpha703") could behave differently than expected at that size. The precedent test (breadcrumb_text_width_tracks_ui_font_size_not_editor_font_size) uses the identical 8/28 pair successfully, so this is low-risk, just noting it wasn't independently re-verified here.

Nits

None.

---

Summary of what I checked

Item 1 (UI font stack, src/gtk/mod.rs): The one-line UI_FONT_FAMILY reorder ("Cantarell, Ubuntu, Segoe UI, Droid Sans, Sans") is exactly the fix the issue asked for — real Linux desktop UI fonts (Cantarell for GNOME, Ubuntu for Ubuntu/Unity) ahead of the Windows/legacy names, Sans kept as the final catch-all. I verified the claimed unblocking condition is real: quadraui's pinned rev (097eb5f4, already the repo's current pin as of e8124c3, landed before this PR) does route draw_tab_bar_icons, draw_status_bar, draw_tree, and draw_menu_bar through self.ui_font (quadraui#624), and vimcode's App::render_content already calls backend.set_ui_font(&UI_FONT()) every frame — so changing UI_FONT_FAMILY today does reach non-dialog chrome, not just dialogs, as the issue required before allowing this change. ui_font_size was correctly left untouched, with a reasoned justification (the ~2% size delta vs. VS Code is dwarfed by the family-driven metric change, and changing both at once would make it impossible to attribute either effect) — consistent with the issue's explicit instruction not to change both blind.

Item 2 (panel separator borders): No vimcode code changes, which is correct per the Platform-Neutrality Rule (no cr.rectangle patch in src/gtk/mod.rs). The commit message reports the scoping outcome: quadraui's AppShell::render/AppShellLayout.divider_bounds already paints a sidebar/editor divider on both backends, but its color is hardcoded (Color::rgb(100, 100, 110)) with no themed parameter or Backend::theme() read-back — I confirmed this directly in the pinned quadraui checkout (quadraui/src/compose/app_shell.rs:662-663), and confirmed vimcode's src/gtk/mod.rs does route its shell layout through quadraui::AppShellLayout/AppShellEvent, so the facility examined is the one vimcode's sidebar/editor composition actually uses. This is a legitimate "file a quadraui issue and stop" outcome per the issue's own decision tree, correctly not implemented in vimcode. The worker flagged it for the coordinator to file on JDonaghy/quadraui since worker sessions don't run gh — that hand-off itself is fine, just make sure it actually gets filed and linked back, since the issue asked for it to be "linked here."

General: No CLAUDE.md changes (coordinator-owned doc untouched). No security surface. No scope creep — src/render.rs and src/core/settings.rs (listed as candidate files) are untouched, correctly, since neither item ended up needing them. The added test follows established codebase conventions (mirrors the pre-existing breadcrumb_text_width_tracks_ui_font_size_not_editor_font_size pattern almost exactly) and asserts on real rendered pixel bounds (find_bounds widths), not on internal state — satisfying the "rendered output, not state" rule.

[JDonaghy]

Review Complete — ✅ Approved

Reviewer findings could not be posted directly to PR #709 (gh pr review was rejected — likely a self-review restriction). Findings are reproduced here.

Note: a completion comment was posted earlier but findings could not be extracted at that time. These are the retroactive findings.

Blocking findings

None.

Non-blocking concerns

• src/gtk/testing.rs (new test tab_label_width_tracks_ui_font_size_not_editor_font_size, ~line 1575): I independently verified (by reading the pinned quadraui rev 097eb5f4 — quadraui/src/gtk/backend.rs::draw_tab_bar_icons/set_ui_font, and confirming src/gtk/mod.rs's backend.set_ui_font(&UI_FONT()) call site and the draw_tab_bar_icons call site are both unchanged by this diff) that the ui_font_size → tab-bar-glyph-width pipeline this test exercises was already live on develop before this PR, wired by the prior Complete Tier 1 of #699: bump the quadraui pin and land #700 items 1, 3 and 5 for real #705/quadraui#624 PR (e8124c3). That means reverting only this PR's actual code change (the one-line UI_FONT_FAMILY reorder) leaves the new test green — it proves the pipeline reaches a previously-untested surface (tab bar), but it does not pin down this diff's change the way CLAUDE.md's "state that the new test was observed RED against unfixed develop" rule asks for. The commit message gives a thoughtful rationale for why family can't be varied directly (no runtime setting; family+size travel as one Pango string; a literal font-swap test would also be font-availability-dependent across machines/CI) but never states an explicit RED-verification, and, per my check, this particular assertion structurally can't be made RED by reverting this PR's diff alone. Recommend one added sentence in the PR clarifying that this test's RED case is "the quadraui#624 wiring missing" rather than "this diff's family string reverted," so nobody later mistakes it for pinning the visual family fix itself.
• Issue VS Code parity (Tier 2b of #699): GTK UI font stack (blocked on quadraui#624) + panel separator borders #704 explicitly says, for item 1: "This item is inherently visual — attach a before/after screenshot to the PR." I found no screenshot/image committed in fc10f01, and the commit message (which is likely the PR body, since it's the branch's only commit) makes no mention of one. I don't have gh access to check the actual PR page for an attached image, so I can't confirm this is missing — just flagging that it isn't visible from the diff/commit I could review, and asking the coordinator (who has gh) to confirm the screenshot is actually attached to PR #704: VS Code parity (Tier 2b of #699): GTK UI font stack (blocked on quadraui#624) + panel separator borders #709 before merge.
• Minor test-robustness note (not verified, since I was told not to run the test suite): tab_label_width_tracks_ui_font_size_not_editor_font_size uses ui_font_size = 28 in a 1400×900 window with three tabs. If the tab-bar rasteriser truncates/ellipsizes long labels under tight width (unlike the breadcrumb path this pattern was copied from), find_bounds("alpha703") could behave differently than expected at that size. The precedent test (breadcrumb_text_width_tracks_ui_font_size_not_editor_font_size) uses the identical 8/28 pair successfully, so this is low-risk, just noting it wasn't independently re-verified here.

Nits

None.

---

Summary of what I checked

Item 1 (UI font stack, src/gtk/mod.rs): The one-line UI_FONT_FAMILY reorder ("Cantarell, Ubuntu, Segoe UI, Droid Sans, Sans") is exactly the fix the issue asked for — real Linux desktop UI fonts (Cantarell for GNOME, Ubuntu for Ubuntu/Unity) ahead of the Windows/legacy names, Sans kept as the final catch-all. I verified the claimed unblocking condition is real: quadraui's pinned rev (097eb5f4, already the repo's current pin as of e8124c3, landed before this PR) does route draw_tab_bar_icons, draw_status_bar, draw_tree, and draw_menu_bar through self.ui_font (quadraui#624), and vimcode's App::render_content already calls backend.set_ui_font(&UI_FONT()) every frame — so changing UI_FONT_FAMILY today does reach non-dialog chrome, not just dialogs, as the issue required before allowing this change. ui_font_size was correctly left untouched, with a reasoned justification (the ~2% size delta vs. VS Code is dwarfed by the family-driven metric change, and changing both at once would make it impossible to attribute either effect) — consistent with the issue's explicit instruction not to change both blind.

Item 2 (panel separator borders): No vimcode code changes, which is correct per the Platform-Neutrality Rule (no cr.rectangle patch in src/gtk/mod.rs). The commit message reports the scoping outcome: quadraui's AppShell::render/AppShellLayout.divider_bounds already paints a sidebar/editor divider on both backends, but its color is hardcoded (Color::rgb(100, 100, 110)) with no themed parameter or Backend::theme() read-back — I confirmed this directly in the pinned quadraui checkout (quadraui/src/compose/app_shell.rs:662-663), and confirmed vimcode's src/gtk/mod.rs does route its shell layout through quadraui::AppShellLayout/AppShellEvent, so the facility examined is the one vimcode's sidebar/editor composition actually uses. This is a legitimate "file a quadraui issue and stop" outcome per the issue's own decision tree, correctly not implemented in vimcode. The worker flagged it for the coordinator to file on JDonaghy/quadraui since worker sessions don't run gh — that hand-off itself is fine, just make sure it actually gets filed and linked back, since the issue asked for it to be "linked here."

General: No CLAUDE.md changes (coordinator-owned doc untouched). No security surface. No scope creep — src/render.rs and src/core/settings.rs (listed as candidate files) are untouched, correctly, since neither item ended up needing them. The added test follows established codebase conventions (mirrors the pre-existing breadcrumb_text_width_tracks_ui_font_size_not_editor_font_size pattern almost exactly) and asserts on real rendered pixel bounds (find_bounds widths), not on internal state — satisfying the "rendered output, not state" rule.