macOS: the preview's decode backend has never been measured #585

Decoder::open picks VideoToolbox or the software decoder from the H.264 profile alone. #583 measured that choice for export and changed it there, introducing DecodeIntent so the preview keeps the old arbitration untouched.

That was a deliberate refusal to generalise, not a conclusion. The preview has never been measured at all.

The two are not obviously the same problem:

• The export wants throughput and nothing else. It won by 28.7 % on the software decoder.
• The preview wants to hold a cadence and to seek — the user scrubs. A hardware decoder's fixed per-frame latency is a bad deal at 200 fps and possibly a fine one at 60 fps, and seek behaviour after avcodec_flush_buffers was not compared at all.
• The preview shares the machine with the editor UI. thread_count = 0 gives the software decoder every core; that may cost more in UI smoothness than it gains in decode headroom. On battery it is a straight loss.

What would settle it, roughly: a scrub-heavy preview session with frame-pacing and CPU sampled per backend, on both power sources. Until someone does that, DecodeIntent::Preview should stay as it is.