project: Keep the buffer associated after an LSP rename also renames the file (#61142)

# Objective

`test_rename_that_also_renames_file` (added in #59104) is
order-dependent: it passes at seed 0, which CI runs, but fails on many
others (e.g. 11, 15, 17). Any unrelated change that schedules one extra
task shifts the deterministic test scheduler enough to flip it at seed 0
too — which is how it surfaced, while working on #61009. The bug it
exposes is real and pre-existing:

#59104 stopped the content swap, but the open buffer still relied on the
filesystem watcher to follow the file to its new path. Depending on the
order the watcher reports the old path's deletion and the new path's
creation, the entry id isn't carried over, and the buffer is stranded at
the now-deleted old path (shown as saved) and never re-associates.

## Solution

Move the worktree entry explicitly after the rename, preserving its id,
the same way `rename_entry` (project panel renames) already does.

## Testing

- `test_rename_that_also_renames_file` now runs 30 seeds to cover both
orderings.

## 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 adheres to Zed's UI standards
([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
and
[icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md)
guidelines)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable

Release Notes:

- Fixed a symbol rename that also renames the file leaving the open
buffer on the old path