Feature Request: emit event for thumbnail download (sibling of tapo_control_media_downloaded)

[maidmaid]

Is your feature request related to a problem? Please describe.
The tapo_control_media_downloaded event fires only for the .mp4 portion of a motion clip — never for the paired .jpg thumbnail that the integration also writes to disk. Consumers that want to back up the pair as a single unit (e.g. to a NAS) have to either:

• Ignore the thumbnail and let it be picked up out-of-band, or
• Wait/poll on the filesystem for the .jpg to appear after the .mp4 event.

I measured the gap between when the .mp4 lands and when the matching .jpg lands across ~7400 staged pairs from two cameras. The thumbnail arrives 0–5s later in 98%+ of cases, ≤10s in 99.8%, with a long tail up to ~20s and a single ~10h outlier. Without an event for the thumbnail, every consumer has to implement the same race-aware workaround.

Describe the solution you'd like
Emit an additional event for the thumbnail download. To keep the change additive (no risk of breaking consumers who treat tapo_control_media_downloaded as "a motion clip was recorded"), I'd suggest a separate event name, e.g.:

event_type: tapo_control_thumbnail_downloaded
data:
  entity_id: camera.cam1
  filePath: /tmp/cam1/thumbs/<start>-<end>.jpg
  # other fields matching tapo_control_media_downloaded

…fired right after the .jpg is fully written, mirroring the existing event's payload shape.

Describe alternatives you've considered

1. Extend the existing event to fire twice — once per file. Simpler from the integration's side, but a behavior change for any consumer that today equates one event with one clip.
2. Add a thumbnail field to the existing event containing the .jpg path, fired once both files are on disk. Avoids a second event but introduces a wait inside the integration (delaying the .mp4 event by the thumbnail download time).
3. Keep working around it client-side with a bounded poll on the expected sibling path. This is what I'm doing now (15s timeout, 1s tick, falls through to an hourly sweep). Works, but every consumer ends up reimplementing it.

Of these I think (1) — a separate event — is the cleanest for everyone.

Additional context
N/A