Let the user control whether iCloud videos download over cellular

[kmch4n]

Summary

Importing a video that lives only in iCloud pulls the full file down. With "Optimise iPhone Storage" on, that is the normal state for older footage, and a bulk import of up to 20 clips can move several GB. The user has no say in when that happens.

The app is offline-first because ski resorts have poor reception. Spending a cellular allowance on a multi-GB download, with no warning, cuts against that.

Why this is not a bug fix

Raised while diagnosing a bulk-import failure (PHPhotosErrorDomain error 3163). That failure came from shouldDownloadFromNetwork: false on the bulk picker and is fixed in 4d4597b; this issue is the separate feature the symptom prompted, filed so the two do not get conflated.

Worth being explicit: a toggle would not have fixed that bug. Turning "don't download from iCloud" on reproduces exactly the broken state — the picker throws for any offloaded video. So this feature has a hard prerequisite that the fix did not: an answer to what the user sees when an iCloud video cannot be imported.

What has to be decided first

• Where the switch lives. A persisted setting, or a prompt at import time when offloaded videos are detected?
• What it keys on. Wi-Fi vs cellular, or download vs never-download? Wi-Fi-only is the familiar model, but it needs a reachability check the app does not have today.
• How offloaded videos appear when downloads are off. They cannot be imported at all. Hiding them from the picker is not possible (the system picker is not ours to filter), so the app must explain the failure well rather than prevent it.
• Whether the size is knowable up front. If the total can be shown before the download starts, a per-import prompt may beat a hidden setting.

Relevant code

• src/app/video-import.tsx — both pick paths pass shouldDownloadFromNetwork: true. Reverting either one to false is what breaks offloaded videos, so a toggle cannot simply flip this flag without handling the throw.
• src/services/mediaService.ts — getAssetInfoWithDownload already tries local-only first and retries with network access, which is the closest thing to a "prefer local" policy today.
• src/app/_layout.tsx and src/services/thumbnailMigrationService.ts — deliberately use shouldDownloadFromNetwork: false for startup work and skip what they cannot read. Any policy here should leave those alone.
• src/database/schema.ts — app_preferences is the key-value store a persisted setting would use.

Acceptance criteria

• The user can tell, before a large download starts, that it is about to happen.
• Whatever the setting is, an iCloud-only video that cannot be imported produces a clear explanation, not a raw error.
• Startup background work keeps its current local-only behaviour.
• Local-only imports are unaffected.

[kmch4n]

#86 investigates the same root cause from the storage side, and reaches a conclusion that bears on the four open questions here.

The picker cannot be told to skip the download: shouldDownloadFromNetwork maps only to PHAssetResourceRequestOptions.isNetworkAccessAllowed, and honouring false makes writeData throw (expo-image-picker/ios/MediaHandler.swift:413-428). So a Wi-Fi-only policy cannot be expressed on the current pick path at all — which is why 4d4597b had to revert 70ef357.

It becomes expressible once the picker is replaced with an expo-media-library grid and the download is an explicit, cancellable job (#86 Phase 3). getAssetInfoAsync(id, {shouldDownloadFromNetwork:false}) resolves with isNetworkAsset: true rather than throwing, so the app can also tell in advance which selected videos are offloaded — which answers "can the user tell before a large download starts" here.

Suggest this issue is resolved as part of that phase rather than separately.