fix(library): decide book availability from metadata, not read probes

[yicheng47]

Problem

Every book in the library shows the iCloud download overlay even though all files are fully materialized on disk and open fine in the reader.

Cause

#289 made availability a first-byte read probe with a 300ms deadline. Measured against a real 357-book library, that breaks two ways:

1. Cold reads are slow on healthy files. A cold first-byte read through fileproviderd takes 0.7–8s per file — 72% of the library exceeds 100ms and virtually everything exceeds the 300ms deadline. list_books therefore marks the whole page unavailable. (Warm reads are fast, which is why the reader still opens books after a beat.)
2. Concurrent probes poison each other. The PROBES_IN_FLIGHT guard reports "unavailable" for any path already being probed. Home triggers list_books from several event listeners; in a two-sweep race over warm files, one call reported 323/357 unavailable and the other 34.

Fix

• is_file_downloaded is now metadata-only: the file has metadata (legacy .icloud-rename eviction leaves none at the real path) and doesn't carry SF_DATALESS (FileProvider-style eviction). No reads, no deadline, and list_books drops its per-book probe threads.
• The read probe survives as is_file_readable behind a new check_book_readable command, used only where fix(reader): surface error when iCloud book file is unreadable #289 needed it: after a reader load failure, to distinguish broken iCloud sync from a broken book (and nudge a re-download). Same bounded-wait and in-flight guarantees.

Testing

• All 256 backend tests pass; probe tests moved to is_file_readable, plus a new test pinning that a hanging path counts as downloaded but not readable
• tsc --noEmit and cargo clippy clean
• Repro harness run against the real library: metadata checks report 0/357 unavailable; old probe logic reported nearly all books unavailable when cold or raced

🤖 Generated with Claude Code