command hq: two columns, with the navigation stacked

It was 16 / 34 / 50 — a category column, a commander column, and the transcript. So half the screen was
navigation for a list holding a handful of commanders (one, on this machine) while the only thing anybody
reads got the other half.

Now the two navigation panels are stacked into one 24% column — commanders on top, categories beneath — and
the transcript takes 76%.

Categories BELOW the commanders, not above: the commanders are what you came for and the categories are how
you narrow them. Above, the filter would push the list down the screen and be read first; below, the list is
at the top where a list belongs, and the categories can grow their own scrollbar without taking room from it.

The categories panel lost seventy pixels of branding — a Radar tile, "Command HQ", "Watchers &
long-running jobs" — which made sense when it owned a column and does not now that it sits at the foot of
one. The screen's own header says Command HQ two inches above it.

`All commanders` and `Uncategorised` moved INTO the scroll box with the categories. They are the same kind of
thing, a filter over the list, and splitting them into a separate nav block above made the second look like a
different mechanism. The heading and the + button stay pinned; only the list scrolls — the same rule as the
theme dropdown.

MIGRATION, and it is the part that could have gone wrong. This key is persisted per account, so the default
alone moves nobody who has opened the screen. No appType was retired either, so `hasAppType` cannot see it
the way the /chat migration could — the test is structural instead: a horizontal root with three children is
the old shape. It terminates because the replacement has two, and replacing outright is safe on a `locked`
screen where the only user contribution is column sizes. Same reasoning, and same trap, as
ChatHistory/index.tsx.

Two of my edits silently did nothing first, because I searched for `officerdb` where the module is
`officerdev` and used replace without an assertion. Both are asserted now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/apps/officer-web/Screens/Dashboard/CommandHQ/CommandHqScreen.tsx

@@ -1,15 +1,29 @@
+import { useEffect } from 'react';
 import type { LayoutNode } from 'officerdev';
 import { WorkspaceView } from 'officerdev';
 import { useDashboardState } from 'state/useDashboardState';
-import { defaultLayout } from './defaultLayout';
+import { defaultLayout, isLegacyThreeColumn } from './defaultLayout';
 
-// /command-hq: nav + grid + detail, all three always mounted (like /chat), selection carried by the URL
+// /command-hq: navigation and detail, all panels always mounted (like /chat), selection carried by the URL
 // — `?category=` for the nav filter, `:sessionId` for the open commander. See `docs/command-hq.md` →
-// "Route, surface, placement" and "Layout, v1".
+// "Route, surface, placement".
 
 export const CommandHqScreen = () => {
   const workspace = useDashboardState<LayoutNode>('screens/command-hq', defaultLayout);
 
+  /*
+    Move a saved three-column layout onto the two-column one.
+
+    The default alone cannot do it: this key is persisted per account, so anybody who has opened the screen
+    keeps the arrangement they had. See `isLegacyThreeColumn` for why the test is structural rather than an
+    appType check, and why replacing outright is the safe direction on a `locked` screen.
+  */
+  useEffect(() => {
+    if (!workspace.isLoaded) return;
+    if (!isLegacyThreeColumn(workspace.value)) return;
+    workspace.setValue(defaultLayout);
+  }, [workspace.isLoaded, workspace.value, workspace.setValue]);
+
   return (
     <div className="h-full w-full pt-2">
       <WorkspaceView