fix(find): survive slow/broken network paths to Raster (#97)

[moskovich]

Fixes #97.

Root cause

Node's happy-eyeballs (autoSelectFamily) gives each address-family connect attempt 250 ms by default. api.raster.art resolves to one IPv4 (Hetzner FI) and one IPv6 address; from Asia the IPv4 RTT is ~250 ms, so the IPv4 attempt is cut off mid-handshake, the IPv6 fallback has no route on v6-broken networks, and the fetch fails — or, when TCP retries stack, stalls with no output at all. NODE_DEBUG=net trace:

connect/multiple: attempting to connect to 65.109.41.181:443 (addressType: 4)
connect/multiple: setting the attempt timeout to 250 ms
connect/multiple: connection to 65.109.41.181:443 timed out
connect/multiple: attempting to connect to 2a01:4f9:c01e:76f::1:443 (addressType: 6)
→ Error: fetch failed

The same command succeeded in isolation when one SYN happened to land under 250 ms — which is why the failure looked random.

Fix (three layers)

1. Entry (index.ts): setDefaultAutoSelectFamilyAttemptTimeout(2500) — a transcontinental IPv4 connect no longer races the speed of light.
2. raster-client: every query carries AbortSignal.timeout(20s), so a stalled request becomes a fast error instead of a silent hang; network failures rethrow as RasterUnreachableError naming the endpoint and the undici cause (bare fetch failed names neither).
3. find: when Raster is unreachable at the coords step, degrade to a one-item playlist with a warning instead of dying — Raster enriches a find; the coords in hand are enough to build something playable.

Verification

• The find: hangs indefinitely on canonical feralfile.com series URL #97 repro (find on the 36 Points Display Edition series URL, previously killed at 90 s and 150 s with no output) now completes: 35 items.
• New tests: unreachable → typed error with endpoint + cause; abort → typed error; every raster fetch carries an abort signal.
• Suite: 447/447, prettier clean.

Noted, out of scope

find on that 1-edition FF series URL expands via Raster to the parent artwork's 35 tokens. Defensible (Raster is the series authority) but arguably surprising for a single-edition series page; flagging rather than changing semantics here.

[feralfile-bot]

Reviewers: 2 (approve: 0, comment: 0, request-changes: 2).

Critical issues

• rasterQuery only converts failures from fetch() itself. A response body that stalls or terminates after headers causes response.text() or response.json() to reject outside that boundary, leaving resolveCoords unable to recognize RasterUnreachableError and perform its promised single-token fallback. Keep response consumption within the network-error conversion boundary while preserving intentional HTTP/GraphQL errors. This was independently identified by both reviewers.

Missing tests

• Add coverage where fetch returns a Response, but its body read rejects with an abort/network error; also verify the find flow degrades to a one-item playlist.

[moskovich]

Both findings addressed in 35b26f1: body consumption now sits inside the network-error boundary — a stalled/terminated body on an ok response throws RasterUnreachableError so the single-token fallback stays reachable, while HTTP-status errors keep their type even with an unreadable body (best-effort text, never masks the status). Tests: mid-stream termination → typed error; 502 + unreadable body → status error; and an end-to-end find run against a mock server that destroys the body mid-stream, asserting the warn + one-item degrade. 450/450.

[feralfile-bot]

Reviewers: 2 (approve: 2, request-changes: 0).

No meaningful findings after re-review. The network-error handling correctly covers both fetch() failures and response-body failures, and the single-token fallback is limited to paths where coordinates are available.