[Bug]: Inconsistent Behavior of `lsd -al` with Symbolic Link Folders on Windows vs. Linux

Nobody has claimed this yet.

- os: Windows
- `lsd --version`: lsd 1.1.5
- `echo $TERM`:
- `echo $LS_COLORS`:

On Windows, when using `lsd -al`, the command does not display the contents of symbolic link folders marked with a trailing `/` (e.g., symlink_dir/). This behavior differs from Linux, where the contents of such symbolic links are shown as expected.

Direcotry Structure:
```
$ lsd --tree test_dir
 test_dir
├──  link_dir ⇒ real_dir
└──  real_dir
├──  config.json
└──  file.txt
```

`link_dir` is created using `mklink /D link_dir real_dir` under `test_dir`

## Expected behavior

```
$ lsd -al test_dir/link_dir/
d---- ? ? 0 B Fri Apr 18 21:33:26 2025  .
d---- ? ? 0 B Fri Apr 18 21:35:18 2025  ..
.a--- ? ? 0 B Fri Apr 18 21:33:19 2025  config.json
.a--- ? ? 0 B Fri Apr 18 21:33:12 2025  file.txt
```

## Actual behavior

```
$ lsd -al test_dir/link_dir/
l---- ? ? 0 B Fri Apr 18 21:34:07 2025  test_dir/link_dir/ ⇒ real_dir
```

Reproduce the Windows case with `lsd -al test_dir/link_dir/` after creating the directory using `mklink /D`, then compare it with the Linux behavior described in the issue. Trace how `lsd` handles symbolic-link directories and trailing slashes; done means the command lists `.` and `..` plus `config.json` and `file.txt` as shown in the expected output.

Written by the indexing model from the issue text.