feat: jj-lib stash with dual-pane browser and Apply… flow

[Ziinc]

Summary

Adds immutable working-copy and commit stashing backed by jj-lib. Stashed changes act like local gist storage: they are parked under treq/stash/… bookmarks, browsed in a dual-pane modal, and can be copied onto any workspace (or new workspace) via Apply….

Backend

• New stashes table in the local SQLite DB
• jj_stash_working_copy / jj_stash_commit / jj_apply_stash_commit / jj_export_commit_git_patch / jj_delete_stash_bookmark
• Core API: stash WC, stash commit, list, apply, delete, get diff, export patch
• Tauri commands + NAPI dispatch wired for all of the above
• Stash bookmarks keep commits reachable and are filtered from branch lists

Frontend

• Dual-pane StashModal with Apply… popover (Home + activity-sorted workspaces) and New workspace…
• New workspace… opens Create Workspace with stash locked; submit is Create & apply stash
• Commits tab: Stash commit parks a commit off the branch into the stash browser (opens modal)
• Archive button on Changes to stash all WC changes
• Command palette: “View Stashed Changes”

Tests / QA

• Rust: WC stash + commit stash + apply/delete/diff/patch
• App-QA screenshots for dual-pane, apply-existing, and commit-stash → apply
  Stash commit action
  Stash modal after commit stash
  Applied on target
  _{To show artifacts inline, enable in settings.}

  

[cursor]

Thin orchestration over jj + local_db: resolve workspace roots, mint bookmark names, and persist metadata (LOC, files, labels) for the browser UI.

• Apply target uses the same . home-endpoint convention as treq mv
• Diff/patch resolve via the stash commit id so the preview is isolated from any target branch

[cursor]

Stash commits are real jj commits kept reachable via treq/stash/… bookmarks (filtered from get_branches).

• Apply overlays stash file values onto the target WC tree (MergedTreeBuilder) so the stash itself stays intact and re-applicable
• Checkout passes old_wc = None after snapshot because tree_state already matches disk — avoids ConcurrentCheckout (same pattern as restore_file)

[cursor]

New stashes table mirrors prompt_history patterns: additive schema in init_local_db, denormalized workspace_label, JSON files_changed.

• Keeps stash index queryable even if a source workspace is later deleted
• Bookmark name stored so delete can drop the jj reachability ref

[cursor]

Dual-pane browser modeled on PromptHistoryModal: list metadata on the left, isolated get_stash_diff on the right.

• More menu: apply-to-workspace submenu (copy semantics), copy as git patch, delete
• Apply does not remove the stash entry — matches the “local gist” re-apply requirement

[cursor]

Apply… UX rationale (this commit)

• StashModal.tsx: nested “Apply to workspace” submenu became a searchable popover so picking among many workspaces stays one interaction; Home is pinned first, then caller-ordered (activity) workspaces. Empty state is controlled (shouldFilter={false}) because cmdk Command.Empty was showing alongside real options inside the Popover.
• useWorkspaceDialogSubmit.ts: create-with-stash uses applyStash after create — stash commits are not in WC history, so move_workspace_changes cannot find them, and apply must remain a copy (stash stays).
• WorkspaceRightPanel.tsx: locked stash row skips the loading spinner so the preselected stash is visible immediately when opening Create from New workspace….
• Submit label checks applyStashId before the “Split N item(s)” branch so the button correctly reads Create & apply stash.

[cursor]

Commit stash rationale

• jj_stash_commit: duplicates the commit’s tree under a treq/stash/… bookmark, then abandons the original so it leaves the branch without losing reachability for apply/diff/patch.
• Apply stays the existing Apply… path (apply_stash copy onto WC / create+apply for new workspace) so parked commits use the same “mv to another/new workspace” UX as WC stashes.
• Commits tab Stash commit opens the stash browser immediately so the next step is apply onto an existing or new workspace.