Move to custom window chrome

[huntharo]

Moves disktree to custom window chrome: the title bar and the app's top bar become one 40 pt strip holding the window controls, the real app icon (assets/disktree.svg) and wordmark, the trail and the view settings. The four-square logo is gone.

Before	After

GNOME (Ubuntu, in a VM)

GNOME asks the client to draw the frame, so the strip draws the buttons on the side GNOME's button layout puts them (right, by Ubuntu's default).

Maximized: restore glyph, no border or ring	Floating: maximize glyph, border, resize ring

Windows 11

Caption buttons on the right at the system's 46 px width, with the hover fill on minimize; the light theme, and the window's own rounded corners and shadow from Windows.

Per platform

• macOS: transparent titlebar, stoplights at (16, 13) so they centre in the 40 pt band; the icon and wordmark start clear of them. The strip moves the window itself (app_owns_titlebar_drag), and a double-click does whatever the system's titlebar setting says. In full screen the stoplight gap closes.
• Windows: minimize, maximize and close on the right, 46 × 40, hit-tested as the system's own caption buttons, so snap layouts and Aero drag still come from Windows.
• Linux: the window still asks for server-side decorations. Where the compositor draws them (Hyprland/Omarchy, KDE), the strip has no controls and the compositor keeps moving and closing the window. Where it asks the client to (GNOME on Wayland), the strip draws close / minimize / maximize on the side GNOME's button layout says, keeping only the ones the compositor supports. It moves on drag, maximizes on double-click and opens the window menu on right-click, and the window gets a border, a shadow and a resize ring on every side that isn't tiled.

Which side the controls go on is decided in one place, chrome::Frame::new.

Kept as they were: the treemap owns the keyboard from the first frame, the minimum window size, and the Wayland app_id disktree. The window title is still set; the Window menu and window switchers read it.

The wordmark folds to just the icon below 70 rem on the explore screen, so the trail keeps its room. On review and the other screens, the strip carries only the brand and a drag area, because those screens have their own header.

Tests

cargo xtask lint and cargo xtask test are green.

• chrome.rs unit tests: what each platform and decoration mode puts at each end.
• Window-harness tests draw the strip on Explore, Review and Done for macOS, macOS full screen, Windows, a server-decorated Linux, GNOME with controls on the right and on the left, and GNOME maximized. They check the strip's height, that the brand stays clear of the controls, and that Windows' buttons sit at the right edge.
• The client-side frame keeps its ring and grips until it is tiled.
• The wordmark gives way in a narrow window.
• A press on the strip arms a move, and a plain click disarms it.

Not run

• Hyprland/Omarchy and KDE were not run, only built and tested in the window harness here. GNOME (Ubuntu, floating and maximized) and Windows 11 were run in VMs (screenshots above); dragging, double-click, snap layouts, the window menu and the resize grips there can't be judged from screenshots.
• The move itself can't run in the harness: the test platform leaves start_window_move unimplemented. On macOS the strip was checked by eye in a release build; dragging, double-clicking and the Windows and GNOME buttons were not exercised by hand.
• Only checked in the default Omarchy theme at the default font size.