fix: stream uploads from disk instead of holding binaries in memory

[riglar]

Summary

Fourth deferred item from the #3 review: the upload pipeline held the entire binary in memory up to three times simultaneously — prepareFileForUpload read it into a File (zipping .app dirs in memory first), the Supabase TUS path copied it again via Buffer.from(await file.arrayBuffer()) (ironic for a "resumable/chunked" protocol), and the Backblaze simple path made a third copy. Large iOS zips could OOM constrained CI runners.

Everything now streams from disk via a small UploadSource descriptor ({ diskPath, name, size, contentType }):

• .app directories are zipped to a temp file through yazl's output stream (removed in a finally) instead of being buffered whole
• SHA-256 dedup hash is computed from a read stream
• the TUS upload feeds tus-js-client a createReadStream with uploadSize — it buffers one 6 MB chunk at a time
• the Backblaze large path now uses the existing readFileChunk disk reads, which were dead code before (the in-memory File always shadowed them)
• the Backblaze simple path keeps a single transient buffer — bounded, since the server only picks that strategy for small binaries, and S3 pre-signed PUTs reject chunked transfer encoding (ruling out a stream body)

Measured result

Peak RSS uploading a 500 MB binary (/usr/bin/time -l, same machine, same mock API):

	maximum resident set size
before	2.18 GB
after	165 MB

Test plan

• pnpm test 122/122 passing (covers the dedup short-circuit and the full --ignore-sha-check upload attempt)
• pnpm build and pnpm lint clean; also verified clean under --strict so it composes with fix: enable TypeScript strict mode and type-check tests in CI #7
• RSS measurement above exercises prepare + hash on a real 500 MB file

🤖 Generated with Claude Code