feat(desktop): deliver a connect-only preview for existing Servers

Feature description

Implement the first connect-only Desktop preview from RFC #1455, as a bounded delivery under #1428. I will follow up on this implementation.

The initial qualification target is Windows 11 x64 with a SQLite-backed Server. The preview connects to an existing installation; it does not install or take ownership of the Server.

The user journey is:

1. Open the installed Desktop application.
2. Connect to an existing Server and inspect the actual identity, readiness, and supported capabilities.
3. Select an authorized exact Scope.
4. Explicitly save a Memory without configuring an inference model.
5. Recall it with full-text search and open its exact entry and citation.

Problem and proposed solution

Create an independent desktop/ application using Tauri 2, React, TypeScript, and Vite. The Rust host owns constrained native capabilities and credential-bearing HTTP transport. The Python Server remains responsible for authorization, business semantics, and persistence.

The UI uses typed IPC and public API operations derived from or checked against openapi/powercontext.yaml. It must not read the database, call Dashboard-private routes, or start a private Server supervisor. Desktop builds remain separate from the documentation website and Python package installation.

Scope and acceptance criteria

• Produce an installable Windows preview and record the exact Desktop, Server, OS/WebView, and selected Agent host versions used for qualification. The UI can open without local Python or a running Server.
• Add, save, and switch connections. Support loopback HTTP and direct remote HTTPS according to RFC transport rules, with actionable certificate, authentication, authorization, and availability errors.
• Store persistent credentials in Windows Credential Manager; support explicit session-only use when necessary, with no plaintext fallback. Secrets do not appear in renderer storage, URLs, logs, diagnostics, or notifications.
• Display the Server-resolved Principal/authentication mode, liveness/readiness, and supported operation groups. Health does not imply authorization or full feature availability.
• Use the Server handshake when available. Until then, allow only explicitly selected compatibility profiles qualified against an exact Server release/commit and contract; do not infer compatibility from successful probes.
• Complete exact Scope selection, explicit Memory save, bounded full-text search, and exact entry/citation inspection against a real Server without model credentials.
• Isolate private results, cursors, and drafts when connections, credentials, or identities change. Late responses cannot populate another connection; submitted writes remain bound to their original target.
• Handle unavailable capabilities, empty results, reconnect, permission denial, and uncertain write outcomes without blind write replay or a persistent offline write queue.
• Where an existing local installation provides them, consume service status --json and doctor integrations --json through constrained native operations. Distinguish declared, observed, and unverified states; absence of local tools is not a remote Server failure.
• Closing or exiting Desktop leaves the independently installed Server running. No service start/stop/install/uninstall action is introduced by this preview.
• Provide English/Chinese text, keyboard navigation, visible focus, safe content rendering, and usable confirmation/error states at small window sizes and 200% scaling.
• Record native packaging/credential evidence and behavioral tests for the real API flow, authorization errors, connection isolation, and recovery. Mock success alone does not qualify the preview. Preserve the applicable P0/P1 gates from the delivery plan.

Out of scope

Managed runtime or Agent installation/upgrades, service/configuration mutations, full Memory directory/history browsing before bounded APIs exist, Review management/notifications, durable Handoff delivery, and claims of qualified macOS/Linux support.

This issue does not replace all P0/P1 evidence or close #1428. Windows remains experimental until the applicable qualification gates pass; record unresolved gates explicitly.

Alternatives considered

• Embedding the existing Dashboard does not provide the required native credential and connection boundary.
• Waiting for all installation, pagination, and delivery dependencies prevents useful independent progress.
• Implementing temporary desktop-only backend APIs would create a second contract to maintain.

Additional context

• Parent tracking issue: #1428.

• Accepted design: #1455 and the Desktop delivery plan.

• Implementation baseline inspected: aa697c5315204249e090acdf1a00d0582e851c5f; this is not a claim of compatibility with every released Server.

• Development starts in my fork's codex/desktop-preview branch. A Draft PR will expose the first reviewable implementation. Unless maintainers request an upstream integration branch, its target is master.

• Public Server/platform dependencies are separate upstream issues and PRs. Handshake and Windows qualification work can proceed alongside Desktop; entry pagination gates full browsing, and history pagination gates the history UI.

• I am willing to contribute code, docs, or design feedback.

Implementation announcement: https://github.com/oceanbase/powercontext/issues/1428#issuecomment-5731702285

Related public capability work

These are separate upstream deliverables, not tasks that all have to finish before Desktop scaffolding starts. The public capability implementations target master; Desktop integrates the merged contracts.

Start with RFC #1455 and docs/en/development/desktop-delivery-plan.md, then inspect openapi/powercontext.yaml and the independent desktop/ application boundary. Done means an installable Windows 11 x64 preview that connects to an existing SQLite-backed Server, completes the stated save/search/citation journey, and records native packaging, credential, API-flow, authorization, isolation, and recovery evidence.