NativeAgentServer::connect used prompt_store.await? which turned any
PromptStore initialization failure (permission denied, disk issues, etc.)
into a hard connection error, preventing all new native agent threads.

Changed to .log_err() so the error is logged at ERROR level but thread
creation proceeds with prompt_store: None. NativeAgent::new already
accepts Option<Entity<PromptStore>> and handles None gracefully — user
custom prompts won't load but threads still work.

Added a regression test that serializes a stale thread ID, loads the
panel (triggering 'last active thread not found in database'), then
verifies NewThread still produces a connected thread.

Same issue as on Linux: after device recovery clears the atlas, a
WM_PAINT arriving during the 200ms recovery sleep could call
draw_window with force_render=false, which unconditionally called
mark_drawable() (clearing skip_draws) and then presented a stale
scene against the empty atlas.

Fix this by adding a force_render_after_recovery flag to the window
state, set during handle_device_lost. The first draw_window call
after recovery reads this flag and forces a full scene rebuild,
matching the Linux approach.

It writes HTML with explanation of how mertic values are derived

- Rename test to reflect canonical grouping behavior and fix assertion
  for worktree unlinking (currently expected-failing, pending prune fix)
- Update PLAN.md to reflect PR #52052 is open, awaiting review
- Extract CanonicalWorkspaceGroups struct from inline tuple
- Extract group_workspaces_by_canonical_path as CanonicalWorkspaceGroups::build
- Refactor gather_historical_threads to return Vec<ListEntry> with
  reduced parameter count (6 read-only params instead of 10 with 3 mut)
- Extract shared render_thread_group function that deduplicates
  query-mode and normal-mode rendering across open workspace groups
  and historical groups (~130 net lines removed)
- Use iterator chain in query path to avoid empty Vec allocation

Refactor how `project_panel::undo::UndoManager` supports redo
operations. The initial plan before this commit was to have a single
`VecDeque` complemented by a cursor, where undoing an operation meant
decreasing the cursor, and redoing meant increasing the cursor.

That works fine for almost all cases but, in the particular case of a
`Create` or `Trash` operation, we'll eventually need to keep track of
the trashed entry when we wish to redo a `Create` operation, or undo a
`Trash` operation.

As such, this commit re-introduces the idea of using two different
stacks, one for the list of operations to undo and one for the list of
operations to redo, namely
`project_panel::undo::UndoManager::undo_stack` and
`project_panel::undo::UndoManager::redo_stack`.

It also updates the overall approach such that:

1. When recording an operation, we invert it and push that to the undo
   stack
2. When undoing, we execute the most recent operation in the undo stack
   and push its inverse to the redo stack
3. When redoing, we execute the most recent operation in the redo stack
   and push its inverse to the undo stack

This makes it so that `UndoManager` more or less only needs to know
which operation to execute and where to push the resulting operation,
allowing us to get rid of `UndoManager::undo_operation` and
`UndoManager::redo_operation` specific methods.

Unfortunately, one thing that was lost in this refactor is that, right
now, we early-return in the `Batch` operation, as soon as a single
operation fails, so we'll always only show one message, we might want to
revisit this later.

Co-authored-by: Anthony Eid <hello@anthonyeid.me>

This reverts commit 61c2a4334ca884ed0070bde239902ae3c81aba21.