desktop M10.3: frontend data-source adapter seam (repo interface + rest.ts)

Extract a typed repository interface (adapters/repo.ts) from the scattered
store/view -> api.* calls, backed by adapters/rest.ts (verbatim HTTP mapping)
and selected through adapters/index.ts. Every store and the notes-facing views
now depend on `repo`, never the HTTP client directly -- the seam the offline
local source (M10.5, over Tauri invoke) plugs into next.

Behavior-preserving for web: rest.ts maps each semantic method to the exact
endpoint the code called before; query-string and multipart building moved out
of the stores/views into rest.ts (the one place that knows the URL shape).
Client-side logic (reconcile/sort/optimistic reorder/toasts) stays in the
stores. GraphView + admin SettingsView keep direct api calls -- out of the
offline-core scope (M10.5 is board/editor/capture/search/filter/labels/
checklists/reminders).

Task 1992.

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

frontend/src/adapters/index.ts

@@ -0,0 +1,19 @@
+// The data source the whole app uses. Import `repo` from here — never reach for
+// `api/client` in stores/views.
+//
+// Today it always resolves to the REST source. M10.5 adds the offline desktop
+// source (`local.ts`, over Tauri `invoke`) and flips this to a runtime choice:
+//
+//   import { isDesktop } from "../desktop/bridge";
+//   import { local } from "./local";
+//   export const repo: Repo = isDesktop() && !hasConfiguredServer() ? local : rest;
+//
+// so a fresh desktop launch runs fully offline, and a server-connected one keeps
+// using REST. Web is unaffected.
+
+import { rest } from "./rest";
+import type { Repo } from "./repo";
+
+export const repo: Repo = rest;
+
+export type { Repo } from "./repo";