Attach media metadata to downloaded files: probe on completion + inherit preview from search results - #321

Problem

After #319, media-metadata probing works, but a downloaded media file didn't get its FT_MEDIA_* tags until the next daemon restart. Two gaps:

1. MaybeScheduleMediaProbe only runs when a file is first inserted into the shared list. A download is shared as a partfile while transferring, so on completion CompleteFileEnded → SafeAddKFile re-adds it, AddFile's insert no-ops (hash already present — the alreadyCanonical branch), and the probe is never scheduled.
2. The search result the download came from already carried the file's media metadata (a source running feat(metadata): advertise Length / Bitrate / Codec for shared media files via ffprobe #280 advertises FT_MEDIA_LENGTH/BITRATE/CODEC), but CPartFile(CSearchFile*) copied only FT_FILETYPE/FT_FILEFORMAT and dropped it (ignored tag 0xD3…), so nothing was shown while downloading either.

Fix

Commit 1 — probe on completion (SharedFileList.cpp/.h): schedule the probe from the completion (alreadyCanonical) branch, once the file is complete on disk in Incoming. QueueProbe only enqueues, so it never stalls completion (rides on #319's isolation). The completion call forces the probe (new bForceReprobe arg bypasses the already-has-FT_MEDIA gate) so the authoritative local ffprobe is the source of truth — it always runs on completion and overwrites anything inherited from the network; startup rescans stay probe-once. Two guards on MaybeScheduleMediaProbe:

• Never probe an in-progress download — a partfile is shared while transferring, so AddFile calls this during the download when there is no complete file to read (<hash>.part). Skip any non-forced probe of a partfile unconditionally (the completion re-enters with the force flag); metadata is derived exactly once, on completion.
• Skip when the resolved path isn't on disk — so a stale known.met record that outlived its deleted file never hands ffprobe a path that can't succeed.

Commit 2 — inherit a preview from search results (PartFile.cpp): add FT_MEDIA_LENGTH/BITRATE/CODEC to the tags CPartFile(CSearchFile*) inherits, so a download shows media metadata immediately while transferring, with no local ffprobe. This is a preview only — the authoritative completion probe re-derives and overwrites it. Source-agnostic: ed2k and Kad share the same tag IDs (TAG_MEDIA_* == FT_MEDIA_* == 0xD3/D4/D5) and the same CSearchFile path, so one change covers both.

Model: inherited network tags give an instant, free preview during the download; on completion the local ffprobe always runs and replaces them with verified values. A media download ends up authoritatively tagged whether or not its source advertised anything — and the network is never trusted as the final answer.

Test plan (macOS, Linux, Windows)

1. Probe on completion — download a media file; on completion (no restart) the log shows queueing → extracted → Media metadata, and known.met gains FT_MEDIA_*.
2. Inherit preview — download one whose search result carried 0xD3/D4/D5: the partfile carries the tags during download, and on completion the probe still runs (extracted, not skip) and overwrites with local values.
3. No stall — completions flow normally throughout (rides on Make media metadata probing safe: dedicated worker, ffprobe timeout, CTag + codec fixes #319).
4. Existence guard — a still-downloading partfile / stale known.met entry is not probed.