v1.40.0

Timer: say whether the graphics card did the encoding (v1.40.0)

On Windows the owner's exports took longer than on the Mac, on a machine
with an NVIDIA card — and nothing could say whether the GPU was being used.
The app probes NVENC, QuickSync and AMF and takes the first that works,
but it recorded the choice nowhere and threw ffmpeg's refusal away, so a
graphics card being skipped looked exactly like having none. It matters
more than it sounds: drawing a 5-minute countdown takes 0.2 s of a 6.2 s
render here, so the encoder is nearly the whole time. The bundled Windows
ffmpeg does include all three hardware encoders — read from the configure
string inside the shipped binary — so the path is real, not dead code.

The timer's ADVANCED drop-down now ends with "Last export": plain words
first ("Made on the graphics card, in 3.1 seconds."), the codec and
ffmpeg's reason on a dim line beneath. Not under the finished filename,
where "h264_nvenc" meant nothing to a volunteer. Analytics gains an
encoder property on the export event, so GPU use is visible across every
church, and on a Windows fallback nvenc/qsv/amf each give a one-word
reason (no_driver, no_device, unsupported, timeout, other). ffmpeg's text
itself never leaves the machine: it can name a DLL by full path, and a
Windows path carries the user's name. A smoke test plants exactly that
and proves none of it reaches analytics. The README says so too.

The first version asked pick_codec() after every job. That named a codec
for PNG exports that encode no video, and fired the hardware probes — up
to a 20 s timeout each on Windows — on transparent exports, whose code
exists to avoid them. It now records the codec the encoder actually used.
Smoke 503/503, golden 23/23 pixel-identical, and the encoder checks were
also run against a simulated GPU-less Windows runner, the state that
turned the v1.39.0 build red. Not verified on Windows itself.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>