[loop cycle 1] perf(dnd): stream dropped files to cut peak memory on large videos

[karem505]

What

Fixes the memory blow-up when dropping large videos. build_drop_payload (the Rust side of drag-and-drop) used to hold ~4 simultaneous full copies of the dropped bytes:

std::fs::read (raw Vec<u8>) → base64_encode (full base64 String) → serde_json::json! (copied into a Value) → serde_json::to_string (copied again into the output)

So a 100 MB video drop peaked near half a gigabyte and could OOM or stall the window thread.

How

• Read each file in 48 KiB chunks and write its base64 once, directly into the output JSON buffer.
• Manual JSON assembly for the array/object structure; serde_json::to_string still escapes the name/type strings (base64's alphabet needs no JSON escaping).
• A 0–2 byte carry keeps base64 emission aligned to whole 3-byte groups across reads (only the final group is padded).
• A mark/truncate rollback keeps out valid JSON if a file read fails partway through streaming its base64.

Peak extra allocation drops from ~4× the file size to ~1.33× the base64 of the single largest file + a 48 KiB buffer. Output shape is byte-for-byte the same [{name,type,b64}] the page injector already expects.

Verification

Gate 1 — deterministic (verify.sh = cargo build --locked + cargo test): PASS — 55 tests (4 new):

• streaming_base64_matches_oneshot_across_chunk_boundary — parity vs the one-shot encoder for a file just past 48 KiB, for each length-mod-3 case (0/1/2)
• empty_file_streams_to_empty_base64
• build_drop_payload_roundtrips_name_type_b64 — parses the JSON, checks name/type/b64 for a png + a 48 KiB+5 mp4
• build_drop_payload_empty_for_no_files — "[]" parity with the old path

Gate 2 — generation-blind code review (separate feature-dev:code-reviewer, told it didn't write the code, default-to-doubt): APPROVE, severity none, no must-fix. Verdict after an exhaustive trace:

• carry/flush logic provably correct for all read-size sequences; carry[carry_len] can never go out of bounds; base64 never mid-stream-padded
• mark/truncate always restores valid JSON; no trailing comma across skips/rollbacks
• behavior parity confirmed (empty → "[]", identical object shape)
• no resource leak / panic / injection (filename is serde-escaped)

Its one non-blocking note (a redundant BufReader around the already-large read buffer) was applied before this PR — the file is now read directly.

Follow-up (not in this PR)

The base64 still crosses into the webview via eval (one more ~1.33× copy on the JS side). Eliminating that transport entirely — serving the dropped bytes over a custom URI scheme and fetch→blob→File in bridge.js — is tracked as backlog item A1 for a later cycle.

---

🤖 PR-ONLY — do not auto-merge. Releasing whatRust is manual via a v* tag; this loop never merges, bumps the version, or tags a release. Opened by the whatrust-fix-loop (cycle 1/6).