fix(output): write atomically so a failed re-run cannot destroy a good file

[rohanpoudel2]

First of three PRs for 2.1.0. The theme across all three is that the tool
should do what its README says it does; this one is the only item that
destroys user data.

The bug

Both encoders wrote straight to the final destination path, and two separate
paths then removed it. With --overwrite over a directory that already had
output from an earlier run, a valid file was lost.

Reproduced on main @ e5982e6:

$ imgvidcompress video ./src -q 40          # creates compressed/clip.mp4
$ cp compressed/clip.mp4 good.mp4
$ imgvidcompress video ./src -q 100 --overwrite
  ○ clip.mp4  skipped — compressing made it bigger, original kept
$ ls compressed/clip.mp4
  No such file or directory

The run reports skipped — output-larger-than-input, whose documented
meaning is that the original was kept and nothing was touched. It had in fact
just deleted the user's previously compressed file. Three routes in:

• encodeVideo() targeted the destination and rm'd it in its failure catch.
• The skip-larger branch in runVideoJob() rm'd the destination outright.
• encodeImage()'s write() used writeFile on the destination, which
  truncates before it writes — an abort mid-write left a truncated file.

The fix

Encode into a hidden staging file beside the destination, rename() onto it
only after the encode succeeds and clears skip-larger. Failure, abort and
skip-larger now remove the staging file only; the destination is never touched
by a run that does not successfully replace it.

Two details that matter:

• The staging name keeps the real extension last (.clip-<uuid>.tmp.mp4).
  ffmpeg picks its muxer from the output extension, so clip.mp4.part would
  have broken every video encode.
• The leading dot means discovery's existing dotfile skip already excludes an
  in-flight encode, so a concurrent or later run cannot pick one up as input.

mapWithConcurrency now settles every worker before rethrowing. Promise.all
rejected on the first abort and left sibling workers' cleanup unawaited, which
stranded staging files on the way out.

encodeImage's encode-to-buffer design is unchanged — it is what makes
skip-larger able to decline without ever putting a worse file on disk.

Verification

Same reproduction on this branch:

status: skipped   reason: output-larger-than-input
previously-good output: SURVIVED, byte-identical
staging residue: none

192 tests pass (up from 184), covering: a failed encode with --overwrite
leaves the prior output intact, a larger-output skip leaves it intact, and no
staging residue after success, failure or abort.

typecheck / lint / format:check / build / build:mcp all clean.

Notes for review

No API, JSON or CLI surface changes — schemaVersion stays 1. The behaviour
change is that skipped — output-larger-than-input is now truthful.

🤖 Generated with Claude Code