feat(ui): the viewer's screens as @colbymchenry/codegraph-ui, behind one adapter (CG-61)

`ui/src` now builds two ways from one tree: the static app `codegraph ui`
serves, and — via `svelte-package` — a Svelte library the Pro app imports.
A forked component would be a second answer to the same question about the
same graph, so there is no fork.

Everything a screen knows arrives through a `GraphAdapter`: eleven methods
answering the wire shapes verbatim, with `createHttpAdapter()` (the loopback
JSON API) as the default and a host's in-process engine reads as the point.
`lib/api.ts` became a one-line-per-call facade over it, which is why no call
site in the views changed. The payload types moved to `lib/wire.ts` — no
imports, no runtime — so a host can depend on the vocabulary alone.

Two more seams and one guard:

- `lib/navigation.ts` holds the href builders behind a `NavigationDriver`, so
  a host addresses its own URL space. The app's half — the hash parser and the
  live route, which attach window listeners at module scope — stays in
  `router.svelte.ts` and is pruned out of the package: rendering a Symbol view
  must not install a hash router in somebody else's application.
- `lib/theme.css` carries the design tokens and maps Svelte Flow's `--xy-*`
  variables onto them, so a host never sees library defaults. Dark now also
  answers to a bare `[data-theme]`, which is how `<CodegraphUi theme>` themes
  a container rather than the document.
- `scripts/check-ui-package.mjs` prunes the app's shell, resolves the
  extensionless specifiers svelte-package leaves behind, and asserts that
  nothing but `lib/adapter.js` reaches the network.

The search box, its keyboard and its panel are one component now
(`SearchPalette`), because splitting them is what breaks a palette.

`__tests__/ui-package.test.ts` mounts the three screens from the package entry
against a mock adapter in jsdom; it runs as a second vitest project so the
`browser` resolve condition it needs cannot reach the engine's suites.

Versioned with the engine. Prepared, not published: `private: true` is the
guard and `pack-npm.sh` only packs a tarball under CODEGRAPH_PACK_UI=1.

vitest.workspace.mts

@@ -0,0 +1,63 @@
+import { svelte, vitePreprocess } from '@sveltejs/vite-plugin-svelte';
+import { defineWorkspace } from 'vitest/config';
+
+/**
+ * Two projects, one command (`npm test` still runs everything).
+ *
+ * The split exists because of exactly one suite. `ui-package.test.ts` mounts
+ * `@colbymchenry/codegraph-ui`'s components against a mock adapter (task
+ * CG-61), and to do that it needs three things the engine's suites must never
+ * see:
+ *
+ *   - the **Svelte plugin**, to compile `.svelte` and `.svelte.ts` modules;
+ *   - **jsdom**, because a component without a document is not a render;
+ *   - `resolve.conditions: ['browser']`, so `svelte` resolves to its client
+ *     build rather than its server one (`mount()` throws on the server).
+ *
+ * That last one is why this is a workspace rather than one config with a
+ * couple of extra fields. `browser` is a package-resolution condition, not a
+ * test setting: applied globally it would also hand the engine's suites the
+ * browser builds of `web-tree-sitter` and friends, and the failures that
+ * causes look nothing like their cause.
+ *
+ * The engine project `extends` the shared base, so the env vars and Node guard
+ * in `vitest.config.mts` still apply to every engine test. The ui project does
+ * not — see the note on it.
+ */
+export default defineWorkspace([
+  {
+    extends: './vitest.config.mts',
+    test: {
+      name: 'engine',
+      include: ['__tests__/**/*.test.ts'],
+      exclude: ['**/node_modules/**', '**/dist/**', '__tests__/ui-package.test.ts'],
+    },
+  },
+  {
+    // Deliberately NOT `extends`: a workspace project CONCATENATES the base's
+    // `include` with its own, so extending here would run all 200-odd engine
+    // suites a second time inside jsdom (and two of them fail there, for
+    // reasons that have nothing to do with anything). This project stands
+    // alone, and it needs none of the base's spawn-related env anyway.
+    plugins: [
+      // The same preprocessor `ui/svelte.config.js` builds with, so the test
+      // compiles what the package ships.
+      svelte({ preprocess: vitePreprocess() }),
+    ],
+    resolve: { conditions: ['browser'] },
+    test: {
+      name: 'ui',
+      globals: true,
+      include: ['__tests__/ui-package.test.ts'],
+      environment: 'jsdom',
+      server: {
+        deps: {
+          // `@xyflow/svelte` ships uncompiled `.svelte` files, so it has to go
+          // through the plugin above rather than be externalised to Node,
+          // which has no idea what a `.svelte` file is.
+          inline: [/@xyflow\/svelte/],
+        },
+      },
+    },
+  },
+]);