[Bug]: iOS: Obsidian silently killed (jetsam) during parallel downloads of large files — downloads are fully buffered in memory

Describe the bug

On iOS, Obsidian is silently killed by the OS (jetsam, no crash log) during the download phase of a sync whenever large files are downloaded in parallel. Downloads appear to be buffered fully in memory before being written to the vault, so concurrency × largest-file-size quickly exceeds the WKWebView memory budget.

Environment / evidence

• iPhone 14 Pro Max (6 GB RAM), iOS 26.6, Obsidian mobile, remotely-save (S3 backend, self-hosted Garage via HTTPS reverse proxy)
• Vault: ~16,300 remote objects, ~5.3 GB, largest files 60–190 MB (PDFs)
• Initial sync with default concurrency=5 and no size skip: app is killed ~30–60 s into step 4 ("upload or download files in parallel"). Plugin log ends exactly after the 4. upload or download files in parallel, with the desired concurrency=5 line; server-side access logs show downloads flowing normally and then stopping mid-stream with no errors, RSTs or timeouts — the client simply disappears. No .ips crash report is generated (memory kill, not an exception).
• Reproducible: >20 attempts, killed every time the queue reached a folder with 60–190 MB files.
• Workaround that fully resolves it: concurrency=1 + initial run with "Skip files larger than 50 MB", then a second run with size unlimited to fetch the few large files one at a time. With one file in flight at a time even 190 MB files sync fine.

Suggested improvements

1. Stream downloads to disk (chunked/ranged GET + incremental append via the vault adapter) instead of buffering the whole object in memory — this is the structural fix for mobile.
2. Short of streaming: make effective concurrency size-aware, e.g. allow only one in-flight download above a threshold (say 32 MB) while small files keep the configured concurrency. This caps peak memory at roughly threshold × concurrency + largest-file without hurting throughput for typical vaults.
3. Consider a lower default concurrency on mobile platforms.

Possibly related: #716 (high memory consumption), #1020 / #324 (Android crashes during sync), #518.

Happy to provide more logs or test builds.