Theme keys treat a code editor as typing

Monaco is neither a textarea nor contenteditable — its modern input surface is a plain div the
EditContext API writes into — so the tagName guard missed it and ctrl+shift+arrow cycled the theme
while somebody was selecting words in a file. `.monaco-editor` is the class its root always carries.

This belongs here rather than in the editor: capture runs window inward, so a global shortcut
registered on window cannot be stopped from a node deeper in the tree. A handler that guards on "am
I typing" is the only place that can answer it.

src/workspaces/theme/src/useThemeKeys.ts

@@ -149,7 +149,20 @@ export function useThemeKeys(options: ThemeKeysOptions = {}) {
         would be indefensible.
       */
       const target = event.target as HTMLElement | null;
-      const typing = Boolean(target && (target.isContentEditable || /^(input|textarea|select)$/i.test(target.tagName)));
+      /*
+        A CODE EDITOR is typing too, and it does not look like it.
+
+        Monaco's modern input surface is neither a textarea nor contenteditable — it is a plain div the
+        EditContext API writes into — so a tagName test misses it entirely and `ctrl+shift+←/→` cycled
+        the theme while somebody was selecting words in a file. `.monaco-editor` is the class its root
+        always carries; `closest` because the event lands on whatever is inside it.
+      */
+      const typing = Boolean(
+        target &&
+          (target.isContentEditable ||
+            /^(input|textarea|select)$/i.test(target.tagName) ||
+            target.closest?.('.monaco-editor, [data-typing]')),
+      );
 
       /*
         Star or unstar the CURRENT theme, from anywhere, list open or not.