Keep the upload destination file open across chunks

[eliasbakken]

Problem

One piece of the investigation into #75/#61 (slow/stalling WiFi uploads). uploadChunk() was opening, writing, and closing the destination file on every single chunk:

f, err := os.OpenFile(path, os.O_APPEND|os.O_WRONLY, 0644)
f.Write(decoded)
f.Close()

For a ~1.2GB image at 3MB chunks, that's ~400 chunks each paying open/close syscall overhead plus whatever flush happens on close - especially costly against the FAT-formatted USB target this writes to.

uploadMagicChunk already gets this right - it opens the file handle once (lazily, on the first chunk) and reuses it for the rest.

Fix

Brings the regular upload path in line with the magic-upload path: uploadStart opens the file once and stores the handle on state.File, uploadChunk just writes to it, uploadFinish closes it (uploadCancel already did this correctly).

Also fixes a real pre-existing bug found along the way: the base64 decode error in uploadChunk was captured but never actually checked.

Not included: the client-side serialized, non-pipelined chunk loop and the base64/JSON wire overhead (~33% inflation) are separate, larger changes - this PR is just the server-side per-chunk overhead.

Test plan

• go build passes
• New test TestUploadChunkRoundTrip: drives upload_start -> ~22 real upload_chunk calls -> upload_finish through the actual handlers (not mocked), verifies the resulting file matches the original payload byte-for-byte - passes
• Verified locally with Fix lastLine() killing the whole process via log.Fatal #93's fix cherry-picked in: full go test ./... passes clean

Note: go test ./... on this branch alone still hits the pre-existing, unrelated lastLine() crash from #93 (not yet merged) - confirmed my new test passes in isolation, and passes as part of a clean full run once #93 is applied.

🤖 Generated with Claude Code