Culling in Detail view downloads each full original raw instead of using local previews

Description of Issue

- When culling in Detail view, moving to the next photo makes Lightroom download that photo's full original raw (~59 MB for a Canon R5 II CR3) from the cloud, even though a local smart preview (2560 px proxy) exists for every photo (all proxies are stored locally) and Detail view is at fit-to-screen.

- Culling a large shoot therefore downloads hundreds of GB. macOS flagged Lightroom for writing 137 GB in 13 minutes (173 MB/s) during one culling session.

- The writer is the libcurl write callback inside WichitaFoundation: the heaviest stack in the macOS disk-write reports ends in WichitaFoundation → fwrite. That function multiplies size × nmemb and only writes when the HTTP status is below 400, and WichitaFoundation contains a statically linked libcurl (CURLOPT_* and Content-Range strings).

Step-by-step Reproduction Instructions

1. Use a cloud library where originals are not all stored locally (Preferences → Local Storage: "Store a copy of all originals" off) but all smart previews are (on). Pick an album of raw photos whose originals aren't local.

2. In Terminal, watch Lightroom's downloads and the files it writes:
   `nettop -p "Adobe Lightroom" -J bytes_in`
   `sudo fs_usage -w -f filesys "Adobe Lightroom" | grep originals/`

3. Open the first photo in Detail view (D) at fit-to-screen, then press the right arrow about once a second for 2 minutes, flagging some with Z / X.

The Expected Result

- Culling at fit-to-screen uses the local smart previews. A full original is downloaded only when it's actually needed

The Actual Result

- Each step to the next photo downloads that photo's full original into Lightroom Library.lrlibrary/<catalog>/originals/2026/2026-10-10/ (e.g. files of 59.5 MB, 59.1 MB, 59.0 MB…).

- 2026-10-19 22:00–23:00: 120 originals (~7 GB) written while Lightroom logged 179 "ag.organize.selectNextPhoto", 57 "selectPreviousPhoto" and 8 "flag.reject" commands; Lightroom received ~2.5 GB in that half hour alone. Writes ran ~1.5× the bytes received.

- 2026-10-18 20:00–21:00: 50 originals during a culling session (26 next-photo commands). The macOS disk-write report for that session (attached) shows 2,147 MB dirtied over 4,380 s, with the memory footprint growing 559 MB → 14.48 GB.

- 2026-10-11 19:25–19:38: macOS log event “137.44 GB of file-backed memory dirtied over 795 seconds (172.83 MB per second average), exceeding limit of 1590.73 KB per second over 86400 seconds”. Same heaviest stack: WichitaFoundation (+3298780 … +3307924) → fwrite. 137 GB ≈ 2,300 originals at 59 MB.

- 2026-10-24 15:35–16:11: a later, separate culling session, at least 263 photo steps, 2.7 GB of originals written to the library, downloaded from directstorage.adbephotos.com. Camera Raw was decoding the full raws meanwhile (dng_read_tiles_task and InterpolateBayer threads busy).

- Control: culling the same shoot in grid view instead (2026-10-19 22:58–23:03, same keys) downloaded no originals and wrote 0 bytes to originals/, while Lightroom received 0.5 MB in total. The downloads are specific to Detail view.

System Details

- Lightroom 9.6 (Mac App Store), build 20260923-1659-a32d844, arm64
- macOS 27.0.1 (26A434), MacBook Pro 16" (MacBookPro18,2), Apple M1 Max, 64 GB RAM
- Cameras: Canon R5m2 and R6m3
- Library: 41,490 photos, 211 albums, 4,818 stacks; local library 78–85 GB (40 GB originals, 29 GB proxies, 12 GB previews); all proxies stored locally, photo cache limit 50 GB
- Working set: an 11,650-photo Canon CR3 shoot