bug: eza hangs indefinitely on macOS when --icons/xattr detection hits a macFUSE mount that returns inconsistent listxattr buffer sizes

# eza hangs indefinitely on macOS when `--icons`/xattr detection hits a macFUSE mount that returns inconsistent `listxattr` buffer sizes

## Description

`eza` can hang indefinitely (observed: killed manually after 30+ seconds, no progress) when listing a directory that contains a macFUSE-mounted path (in my case, a Syncplicity sync client mount). The hang is caused by a retry loop around `listxattr` that never terminates when the underlying filesystem gives inconsistent size answers across calls.

Related to #1049, though that report points at `fileproviderd`/`--git`; this report isolates the hang to `listxattr` specifically (reproducible without `--git`) and includes syscall-level tracing (`sample`/`fs_usage`) showing the exact retry loop against a macFUSE mount.

## Environment

- eza version:
```
eza - A modern, maintained replacement for ls
v0.23.4 [+git]
https://github.com/eza-community/eza
```
- Install method: Homebrew (`/opt/homebrew/*/eza`)
- OS: macOS 26.5.1 (25F80), Apple Silicon (ARM64)
- Mount in question: `Syncplicity@macfuse0` on `/Users/USERNAME/SyncDrive` (macfuse, nodev, nosuid, synchronous)

## Steps to reproduce

1. Have a macFUSE-backed mount present in the directory being listed (e.g. a Syncplicity, or similar third-party sync client mount)
2. Run:
```
eza -ghl --group-directories-first --git --icons=auto ~
```
3. Command hangs indefinitely with no output and no completion.

## Diagnostics

`time` on the command (killed via 30s external timeout):
```
gtimeout 30 eza -ghl --group-directories-first --git --icons=auto ~ > /tmp/eza_full.txt 2>&1
0.19s user 5.19s system 17% cpu 30.011 total
exit code: 124
```
Zero bytes written to output even partially — nothing hangs on flushing, the process itself never gets past scanning.

`sample` (macOS profiler) on the hung process shows one worker thread spending virtually 100% of its sampled time inside `listxattr`:
```
Sort by top of stack, same collapsed (when >= 5):
__psynch_cvwait (in libsystem_kernel.dylib) 101472
listxattr (in libsystem_kernel.dylib) 4220
```
(all other worker threads are idle in `pthread_cond_wait`, confirming this is a single-thread infinite loop, not a deadlock across threads)

`fs_usage -w -f filesys` confirms the specific path being hit repeatedly, sub-millisecond apart, for the entire capture window:
```
17:02:50.595878 listxattr [ 34] /Users/USERNAME/SyncDrive 0.000116 eza.PID
17:02:50.596045 listxattr /Users/USERNAME/SyncDrive 0.000160 eza.PID
17:02:50.596234 listxattr [ 34] /Users/USERNAME/SyncDrive 0.000179 eza.PID
... (repeats continuously, alternating error code 34 / success)
```
Errno `34` = `ERANGE`. The pattern suggests eza calls `listxattr(path, NULL, 0)` to size the buffer, allocates based on the returned size, then calls again — and the mount reports a different/inconsistent size on the second call, triggering `ERANGE` and an apparent retry, which never converges against this particular mount.

## Expected behavior

`eza` should not be able to hang indefinitely due to a single filesystem's inconsistent `listxattr` responses. At minimum, a bounded retry count (with fallback to treating the entry as having no queryable xattrs) would prevent an unbounded loop. This would also protect against any other misbehaving FUSE/network filesystem, not just this specific one.

## Workaround

Excluding the mount via `-I`/`--ignore-glob`, or unmounting it, avoids the hang. But since the underlying cause is eza's xattr-handling loop rather than anything users can fix on their end, it seems worth hardening against.

## Additional notes

- Plain `stat`/`ls -la` against the same path returns instantly — this is specific to the `listxattr` code path (used for icon/type detection with `--icons`), not general directory traversal.
- Happy to run additional diagnostics or test a patched build if useful.

Start by reproducing the hang with the reported `eza -ghl --group-directories-first --git --icons=auto ~` command, then locate the xattr detection code and its `listxattr` retry loop; no source file or test is named in the issue. Done means inconsistent `listxattr` responses cannot cause an unbounded hang, with the existing behavior preserved for normal filesystems and coverage for the failure path.

Written by the indexing model from the issue text.