- worktree_restore_tasks HashMap on Sidebar tracks in-flight restore
  operations keyed by SessionId
- Restore task is now stored (not detached) so it can be tracked and
  the pending state cleaned up when it completes
- cancel_worktree_restore drops the task from the map and notifies
- ThreadItem wired up with pending_worktree_restore bool and
  on_cancel_restore callback from the Sidebar's render_thread
- Action slot (archive/stop buttons) hidden while a restore is pending
- Reconciled with existing PR4 restore spinner in worktree labels

## Context

When the dev container creation modal is showing "Creating Dev
Container", clicking anywhere on the workspace backdrop dismisses the
dialog. The container creation continues in the background, but the user
loses visual feedback and the subsequent `open_remote_project` call may
fail because the modal entity is gone.

This adds an `allow_dismissal` flag to `RemoteServerProjects` that
blocks accidental dismissal (backdrop clicks, focus loss) while a dev
container is being created, but allows explicit dismissal on success or
error.

## How to Review

Small PR — two files changed:

1. **`remote_servers.rs`** (the fix): `allow_dismissal` bool field
added, set to `false` when entering Creating state, set to `true` before
emitting `DismissEvent` on success/error. `on_before_dismiss` override
checks the flag.
2. **`recent_projects.rs`** (the test): Regression test that opens a dev
container modal, simulates a backdrop click, and asserts the modal stays
open.

## Self-Review Checklist

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

Release Notes:

- Fixed dev container creation modal being dismissed when clicking
outside it

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

The read_skill tool validates that requested paths are within a skills
directory by canonicalizing the input path and checking it starts with
the skills root. However, when skills are symlinks (e.g. pointing to
~/.config/zed/superpowers/skills/), canonicalization resolves the symlink
to its target, which no longer starts with the non-canonicalized skills
root.

Fix by also canonicalizing the skills root paths before the starts_with
check, so symlink targets are correctly recognized as being within the
skills directory.

Also update skills_prompt.hbs to reference the read_skill tool instead
of read_file/list_directory, which are project-scoped and cannot access
the global skills directory.

When you manually scroll up in a thread while a long assistant response
is still streaming, the view could slowly drift as the message kept
remeasuring and growing. That happened because the list preserved scroll
position as a proportional offset within the top visible item, so each
height change slightly shifted the viewport. This change makes list
remeasurement preserve the same absolute pixel offset within the top
item instead, which keeps manually positioned thread views stable while
content continues streaming.

Refactoring in #53101 broke manual scrolling in many ways. This change
restores it, accounting for the new FollowMode enum.

Avoid crashes on devices that cannot use the preferred color atlas texture format by selecting a supported fallback during renderer setup and recovery.

The file watcher was racing with directory deletion, causing
'root path could not be canonicalized' and 'reference HEAD not found'
errors. Now we remove the worktree's workspace from the MultiWorkspace
(stopping the file watcher) before deleting the directory.

Also fix directory deletion order: delete the directory first (it may
have uncommitted files that prevent git worktree remove --force from
succeeding), then clean up git's worktree registration.

On the restore side, clean up any stale worktree registration before
creating, to handle registrations left over from previous archives.

Self-Review Checklist:

- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

Closes #52882, should help #52723

According to the [Zed
documentation](https://zed.dev/docs/semantic-tokens#example-disabling-a-token-type),
users should be able to disable semantic highlighting for a specific
token type by adding an empty rule in `settings.json`.

However, the current implementation fails to respect this because its
merging logic allows lower-priority default styles to "leak through"
even when a matching high-priority rule is empty. This makes it
impossible to selectively disable semantic tokens to reveal the
underlying Tree-sitter highlighting when using "semantic_tokens":
"combined". This is particularly problematic for extensions that provide
specialized Tree-sitter queries which are currently being obscured by
less desirable semantic tokens(#52723).

This PR fixes the logic to ensure that a completely empty high-priority
rule acts as an opaque override, correctly disabling semantic styling
for that token type and allowing Tree-sitter highlighting to show
through as intended.

Release Notes:

- Fixed a bug where semantic token highlighting could not be disabled
via empty rules in `settings.json`.

The git_store::Repository::create_worktree wrapper takes String (not
Option<String>), but the merge left test callsites passing Some(...).