arrows are the only global binding

`ctrl+shift+h`/`l` are gone. The arrows do that job, and two spellings for one action is
what invited the reasonable guess that `ctrl+shift+j` moved down — which opens the
browser console.

Worth recording that the reported conflict was not one we had: nothing bound
`ctrl+shift+j`. The global letters were `h` and `l` only, and the `j`/`k` keys live
inside the list with NO modifier. But an interface that makes someone guess a wrong key
is the interface's fault, not the guess's.

Inside the list the vim keys stay, unmodified: `j`/`k`/`l`/`h` beside `↓`/`↑`/`→`/`←`.
Nothing there can collide with a browser shortcut, and this is a vim person's
application.

Verified: `ctrl+shift+l` no longer cycles, `ctrl+shift+→` does, and `j` then `l` still
browses inside the list.

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

src/apps/officer-web/Screens/Dashboard/Layout/Header/ThemeSwitcher.tsx

@@ -44,7 +44,7 @@ export const ThemeSwitcher = () => {
       <DropdownMenu>
         <DropdownMenuTrigger asChild>
           <button
-            title={`Theme: ${theme.name}  ·  ctrl+shift+space for the list, ctrl+shift+←/→ to cycle`}
+            title={`Theme: ${theme.name}  ·  ctrl+shift+←/→ to cycle · ctrl+shift+space for the list`}
             aria-label="Theme"
             className="flex h-8 w-8 items-center justify-center rounded-full transition-transform hover:scale-110 cursor-pointer"
             style={{ color: 'var(--header-fg)' }}
@@ -54,7 +54,7 @@ export const ThemeSwitcher = () => {
         </DropdownMenuTrigger>
         <DropdownMenuContent align="end" className="z-50 max-h-[70vh] w-56 overflow-y-auto">
           <DropdownMenuLabel className="text-xs font-normal text-muted-foreground">
-            ctrl+shift+space · ctrl+shift+←/→
+            ctrl+shift+←/→ · ctrl+shift+space
           </DropdownMenuLabel>
           <DropdownMenuSeparator />
           {Object.entries(families).map(([family, entries]) => (