Fix tab-bar gap after shell exit with hide-if-single

[0x0aa]

Summary

Fixes #1514 — with navigation.hide_if_single = true and two tabs open, exiting the shell in one tab leaves a single tab but keeps an empty strip reserved at the top where the tab bar used to be. The terminal content stays shifted down until the next event triggers a re-layout.

Reproduced on Arch Linux / Sway (Wayland). The affected handler in application.rs runs on Linux and Windows, so the fix should apply equally on both.

The bug

There are two ways to go from two tabs to one with hide_if_single on:

• Closing the tab via the close-tab shortcut — handled by Screen::close_tab in screen/mod.rs, which already calls resize_top_or_bottom_line(1) followed by current_grid_mut().update_dimensions(&mut self.sugarloaf) and render(). This path works.
• The shell exiting on its own (e.g. typing exit) — handled by the RioEvent::CloseTerminal branch in application.rs. This path only called resize_top_or_bottom_line(size). The margin was recomputed, but update_dimensions was never invoked, so sugarloaf.set_position kept the old origin and the freed tab-bar strip stayed empty until something else forced a re-layout.

The fix

In application.rs, mirror what Screen::close_tab already does for the shortcut path: after resize_top_or_bottom_line, call current_grid_mut().update_dimensions(&mut sugarloaf) and screen.render() so the new scaled margin is pushed to sugarloaf and the frame is redrawn immediately.

Test plan

• With navigation.hide_if_single = true and two tabs open, type exit in one tab — the remaining tab's content moves up to the top of the window with no empty strip.
• Same config, two tabs open, close one tab via the close-tab shortcut — behavior unchanged (still no gap).
• With hide_if_single = false and multiple tabs, exit a shell — the tab bar remains visible and laid out as before.

Debugging and the proposed fix were generated with the assistance of Claude — please review critically.

[shiena]

Thanks for this — I ran into one additional transition that the PR as written doesn't cover, so I put the follow-up on top of your branch for reference:

• Branch: https://github.com/shiena/rio/tree/0x0aa-fix-hiding-plus-predicate
• Added commit: shiena@851ce06 — fix: detect margin transitions from the grid's scaled_margin

The extra case:

Screen::resize_top_or_bottom_line gates its margin update behind a comparison against Context::dimension.margin, but ContextGrid::apply_taffy_layout zeroes dimension.margin on every run (frontends/rioterm/src/layout/mod.rs:917). After
the first layout pass, that "previous margin" is always (0, 0, 0, 0). Walking 1 → 2 → 1 tabs with hide_if_single = true:

1. 1 → 2: previous_margin.top = 0, padding_y_top = 34 → predicate is true, update_scaled_margin runs. The subsequent apply_taffy_layout zeroes dimension.margin.
2. 2 → 1: previous_margin.top = 0 (zeroed in step 1), padding_y_top = 0 (hide-if-single + 1 tab) → predicate is false, update_scaled_margin is skipped, and the grid's scaled_margin.top stays at 34 * scale.

The update_dimensions call this PR adds in CloseTerminal then runs apply_taffy_layout, which computes rich-text position as (abs_y + scaled_margin.top) / scale = 34. The island is hidden but the rich text still starts ~34 px down — the
same visual gap this PR is trying to close.

The same early-exit also catches the close-tab shortcut path. On Windows 11 with hide_if_single = true, opening a second tab and closing it via the close-tab shortcut leaves the top strip blank even with this PR applied.

The extra commit switches the comparison to the grid's own scaled_margin (which apply_taffy_layout does not clear), and with it the update_dimensions + render this PR adds starts seeing a correctly-updated scaled_margin. The existing 22
tests in layout/compute_tests.rs still pass.

[0x0aa]

Fixed in main