fix(core): resolve symlinks to directories in file listing

[notsobad]

Issue for this PR

Closes #

Type of change

• Bug fix

What does this PR do?

FileSystem.Service.list filtered out all symlink entries, so symlinks to directories were invisible in the directory picker and other file browsing contexts. readDirectoryEntries returns "symlink" type for symlinks, but the flatMap in list discarded anything that wasn't "file" or "directory".

The fix resolves symlinks via stat (which follows the link) and includes them with the resolved "file" or "directory" type. Broken symlinks are silently skipped via Effect.option. No schema or handler changes needed since the output type remains "file" | "directory".

How did you verified your code works?

I traced the code path: readDirectoryEntries classifies symlinks as "symlink", which then gets filtered out in list. The fix follows the same pattern as ReadToolFileSystem.list which already resolves symlinks via stat. The code compiles correctly with the added Option import.

Screenshots / recordings

N/A

Checklist

• I have verified my changes locally
• I have not included unrelated changes in this PR

[github-actions]

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

• PR description is missing required template sections. Please use the PR template.
• No issue referenced. Please add Closes #<number> linking to the relevant issue.

Please edit this PR description to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential duplicate PRs found:

1. #28532 - fix(filesystem): resolve symlink/junction targets to directory type in readDirectoryEntries

   • Directly addresses the same issue: resolving symlinks to their proper type in directory entries

2. #29102 - fix(opencode): follow symlinks in file scan and directory listing

   • Related fix for following symlinks in file browsing contexts

These PRs appear to address the exact same problem: symlinks not being properly resolved and displayed in file listing/directory picker functionality. Check their status and implementation details to avoid duplicate work.