Give the desktop the second design too, and the window the size it now needs

The desktop v2 design is the other half of the one the phone took last commit, and this is its chrome: a
190-pixel labelled sidebar where the 54-pixel icon rail was, a titlebar with the search box centred in it,
and session tabs drawn as pills. The palette was already here — it is shared, and moved when the phone's
did — so what this changes is shape rather than colour.

**The window's minimum grew, and by exactly what v2 added.** The sidebar is 136 wider and the chrome 14
taller, so 880x560 became 1016x574. That is not a round number somebody liked: it leaves every screen the
same 826x464 it was designed against, which is the arithmetic the layout suite is built on. Four of the
tables stop fitting at 690 wide, so widening the sidebar and leaving the window alone would have broken
them somewhere no test was looking. LayoutHarness carries the new constants and the suite still passes at
the minimum, which is the whole reason it exists.

The rail's five-character abbreviations are gone with the width that caused them — PINS and SNIPS are Pins
and Snippets again — and each row gains a glyph and a count. A count is drawn only where one is real, so
SFTP, Logs and Preferences show nothing rather than a zero: a transfer queue's depth is not how many files
a screen holds, and a log has no total until it is read. The count beside Pins is the vault's own, not the
Pins screen's VisiblePins, which is the filtered list and would have made the sidebar count whatever
somebody had just typed into a filter box on another screen. Teams has no count for a related reason: they
are read from the server when that screen is opened rather than on unlock, so a number there would read 0
until somebody had already been to look.

One colour moved with it, finishing what the repalette started: the live-session summaries on the unlock and
sign-out cards were Info, so the two heads disagreed about a fact the phone paints green. They match again.

**Buckets became a destination rather than a mode**, which is what the design draws and what the phone
already does. The HOST / BUCKET pair inside the files screen is gone; ShellScreen.Buckets draws the same
TransfersScreen with the other picker, and the sidebar entry is what sets it. That also settles an old
disagreement rather than merely moving it: TotalItemCount is keys plus passwords and excludes buckets, so
the number beside the keychain used to disagree with the list under it, and now counts what that screen
shows.

There is one session behind both file destinations, so asking for the other kind while something is open is
refused rather than obeyed — and refusing means staying put. An earlier turn of this had it move anyway and
only decline to switch the picker, which put the S3 entry in the sidebar over a screen still listing an
SFTP host: two pieces of chrome disagreeing about where you are, which is worse than the navigation simply
not happening. The message that says so goes to Transfers.Status, which turned out to be drawn in the same
grid cell as the connected chip — survivable while it was mostly read before connecting, and not once a
refusal reports itself there. It has its own column now.

The design has nine entries' worth of screens and draws five. Pins, Teams, Import and Preferences are
built, working screens, so they keep their entries — the sidebar is labelled now and has the room, and
dropping an entry would have stranded a screen rather than simplified anything. The Team vault card the
design pins to the foot is not drawn: it is a second route to a screen already in the list, carrying a seat
count nothing here produces.

**The status bar survives the design that deletes it**, cut down to one thing. Two of the three facts it
carried moved into the titlebar with v2 — the sync word is beside its dot and the shortcut hint is inside
the box that uses it — so those are gone from it rather than printed twice. The third is Vault.Status, the
only channel this application has for saying a save failed or a merge picked a winner. The design is a
mock-up of an afternoon that goes well and has nowhere to put a sentence like that; dropping the bar would
have meant dropping the sentence or repeating it on nine screens.

What v2 draws and this does not is in docs/design-import-gaps.md, and it is the same list as the phone's
for the same reasons: the forwarding screen and both its chips, the host detail's fingerprint, tags and
last-session cards, the keychain's rotate button, the logs' FOLLOW pill and severity filters, and the
session footer's latency. The terminal is not inset behind a rounded frame either — it is a native child
window that composites above everything Avalonia paints, so the frame would clip nothing, which is the same
answer the phone gave.

**The light theme is not built.** Its accent is #6D5AE6, a different hue rather than a tint of the dark
one, so it needs every colour doubled, a variant to switch on, the renderer's own page switching with it,
and contrast checked twice. That is a piece of work rather than a setting, and it is separable from the
layout — which is why this commit is the layout.

The screens themselves are restyled through the shared vocabulary rather than rebuilt: corner radii,
chips, cards and the accent's ink, all in App.axaml, so every screen moves at once. Their layouts are left
alone deliberately. The design draws read-only detail panes and these screens carry the editors and forms
it has no equivalent of, so replacing a layout with the mock-up's would have lost the half that is
actually used.

Verified by the whole suite: 1309 tests over nineteen projects, none failing, including the 68 layout cases
that stand up real Avalonia and measure every screen at the new minimum. Both heads build. Not run on a
machine with a display — see docs/manual-checks.md for what wants looking at.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AZE3u99BNt6LzgTC5jhbz2

tests/DodoSSH.Client.App.Layout.Tests/LayoutHarness.cs

@@ -31,28 +31,28 @@ internal static class LayoutHarness
     /// two constants still match the XAML, so the harness cannot quietly start measuring a window larger
     /// than the one a user is allowed to drag to.
     /// </remarks>
-    internal const double MinimumWidth = 880;
+    internal const double MinimumWidth = 1016;
 
     /// <inheritdoc cref="MinimumWidth" />
-    internal const double MinimumHeight = 560;
+    internal const double MinimumHeight = 574;
 
     /// <summary>The host sidebar's fixed width, from the hosts screen's <c>ColumnDefinitions</c>.</summary>
     internal const double HostSidebarWidth = 268;
 
     /// <summary>The nav rail's fixed width, from <c>NavRail.axaml</c>.</summary>
-    internal const double NavRailWidth = 54;
+    internal const double NavRailWidth = 190;
 
     /// <summary>
     /// What the titlebar, the tab strip and the status bar take off the window before any screen gets a
     /// pixel.
     /// </summary>
     /// <remarks>
-    /// All three are fixed heights declared in their own markup — 38, 34 and 24 — rather than shapes that
+    /// All three are fixed heights declared in their own markup — 44, 42 and 24 — rather than shapes that
     /// grow with their contents, which is what makes stating them here honest. Three tests hold the three
     /// controls to those numbers, so the budget below cannot drift away from what the window actually
     /// leaves.
     /// </remarks>
-    internal const double TitleBarHeight = 38;
+    internal const double TitleBarHeight = 44;
 
     /// <inheritdoc cref="TitleBarHeight" />
     internal const double StatusBarHeight = 24;
@@ -63,10 +63,10 @@ internal static class LayoutHarness
     /// <remarks>
     /// It comes off every screen, not just the hosts screen, which is the layout consequence of the strip
     /// spanning the window. The strip does not collapse when there are no tabs — a row of chrome that came
-    /// and went would move every screen up and down by 34 pixels each time the last tab closed — so this is
+    /// and went would move every screen up and down by 42 pixels each time the last tab closed — so this is
     /// a fixed cost rather than a conditional one, and the budget can be a constant.
     /// </remarks>
-    internal const double TerminalTabsHeight = 34;
+    internal const double TerminalTabsHeight = 42;
 
     /// <summary>
     /// What a setup card leaves its contents: its maximum width, less the padding on both sides.

tests/DodoSSH.Client.App.Layout.Tests/ScreenLayoutTests.cs

@@ -905,7 +905,7 @@ public sealed class ScreenLayoutTests : IAsyncLifetime
     /// silently dropping off the bottom would still pass every other assertion here.
     /// </remarks>
     [Fact]
-    public async Task TheNavRailHoldsEightDestinationsAtTheWindowsMinimum()
+    public async Task TheNavRailHoldsNineDestinationsAtTheWindowsMinimum()
     {
         await LayoutHarness.OnTheUiThreadAsync(
             () =>
@@ -918,17 +918,18 @@ public sealed class ScreenLayoutTests : IAsyncLifetime
                 {
                     var buttons = rail.GetVisualDescendants().OfType<Button>().ToList();
 
-                    buttons.Count.ShouldBe(8, "one per screen the rail reaches");
+                    buttons.Count.ShouldBe(9, "one per screen the rail reaches");
 
                     foreach (var button in buttons)
                     {
                         button.Bounds.Height.ShouldBeGreaterThan(20);
 
-                        // One pixel narrower than the rail, because the rail draws its own divider down its
-                        // right edge and that comes out of the content. Stated exactly rather than as a
-                        // lower bound: a button that stopped filling the rail would leave a dead strip
-                        // beside every destination, which is precisely the kind of near-miss a bound hides.
-                        button.Bounds.Width.ShouldBe(LayoutHarness.NavRailWidth - 1);
+                        // 190 wide, less the divider down the rail's right edge, less the 8 of inset on
+                        // each side that v2 gives the rows so a filled one reads as a rounded row rather
+                        // than as a full-width band. Stated exactly rather than as a lower bound: a button
+                        // that stopped filling the row would leave a dead strip beside a destination, which
+                        // is precisely the kind of near-miss a bound hides.
+                        button.Bounds.Width.ShouldBe(LayoutHarness.NavRailWidth - 1 - 16);
                     }
 
                     LayoutHarness.Unreachable(window).ShouldBeEmpty();