## Objective

Dragging a folder onto the Zed dock icon (or otherwise opening it by
path) failed
when the folder's name ended in a parenthesized number, e.g. `Test (1)`
or `Test (2,3)`. Instead of opening the folder, Zed opened a
  non-existent, truncated path (`Test `), so nothing useful appeared.

The cause is `PathWithPosition::parse_str`, which supports MSVC-style
position
suffixes like `file.c(22)` → file `file.c`, row `22`. A folder named
`Test (1)`
was therefore parsed as path `Test ` at row `1`.
`derive_paths_with_position` has
a guard that restores the literal path when it exists on disk — but it
only
checked `fs.is_file(...)`, so directories never qualified and the
truncated path
  was used.

  ## Solution

In `derive_paths_with_position`, restore the original path when it
points to an
existing file **or directory** (`fs.is_file(...) || fs.is_dir(...)`),
instead of
  files only.

  ## Testing

- Added
`test_derive_paths_with_position_directory_with_position_like_name`,
which
opens `Test (1)`, `Project (2,3)`, and `test project` directories and
    asserts the full paths survive with no row/column.
- Added `test_parse_str_treats_paren_suffix_as_position` in `util`
documenting the
    underlying `parse_str` behavior that necessitates the guard.
- Manually verified on macOS: built a debug `Zed Dev.app`, dropped
folders named
    `Test (1)` onto the dock icon — it now open correctly;
    previously a non-existent folder was opened.

  ## Self-Review Checklist:

  - [x] I've reviewed my own diff for quality, security, and reliability
  - [x] Unsafe blocks (if any) have justifying comments — N/A, no unsafe
  - [ ] The content adheres to Zed's UI standards — N/A, no UI change
  - [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable — one
extra `is_dir`
stat only when a path parses to a row and differs from the original

  ---

  Release Notes:

- Fixed folders whose names end in a parenthesized number (e.g. `Test
(1)`) failing to open from the dock or by path