fix: handle listxattr errors on macOS

[kokhlo]

Closes #1850.

The hang

Reading extended attributes is a two call protocol. The first call passes no buffer and gets back the size, the second passes a buffer of that size and gets the data back. When the second call fails with ERANGE the buffer was too small, so the read is retried against a freshly asked for size.

That retry had no limit. A file system that keeps reporting a size its own second call then rejects never lets the loop finish, and since this runs per entry while listing, eza never finishes listing the directory. The fs_usage trace in the report shows exactly this: listxattr against the mount alternating between a size and ERANGE for as long as the capture runs.

The fix

Bound the retries at MAX_ERANGE_RETRIES = 5 and return the error once they are used up. A mount that cannot be queried now costs one log line and a listing that completes, instead of a listing that never does.

Retries that do converge are unaffected, so a size that grows once between the two calls is still picked up. Errors a larger buffer cannot fix are still reported immediately rather than retried.

File::gather_extended_attributes already logs a failed lookup and carries on with no attributes, so the error path needed no change.

Tests

Three tests drive get_loop with a stand-in for the file system:

• one that refuses every buffer, which is the hang, and which now returns ERANGE after a bounded number of calls
• one whose size grows once, which still recovers
• one that fails with an error a larger buffer cannot fix, which is not retried

The first test does not pass against the previous code, where it spins instead of returning. Full suite: 358 passed, 0 failed.