fix(commands): match notification cache-key format so writes share one namespace

common._format_assets was passing cache_key=<bare asset UUID>, but the
notification dispatcher writes keys as <host>:<uuid> (derived from the
URL by extract_asset_id_from_url). Result: the two paths populated
different keys for the same asset, so neither could hit the other's
cached file_id and the WebUI stats only ever reflected the notification
side.

Drop the explicit cache_key — TelegramClient derives <host>:<uuid> from
the URL, identical to the notification path, so one file_id cached by
any dispatch or /random / /latest reply is reused by every later send.

packages/server/src/notify_bridge_server/commands/immich/common.py

@@ -135,6 +135,14 @@ def _format_assets(
         # paths agree on video → /video/playback and photo → thumbnail. When
         # these diverged, Telegram rendered a still JPEG for each video in
         # the media group instead of the real clip.
+        #
+        # We deliberately do NOT pass ``cache_key`` here. TelegramClient
+        # derives it from the URL as ``<host>:<uuid>`` — identical to what
+        # the notification dispatcher produces via extract_asset_id_from_url.
+        # Passing the bare UUID would put command writes in a separate
+        # namespace from notification writes, so neither path could hit the
+        # other's cached file_ids (which is what made the cache look empty
+        # from the WebUI after running /random).
         media_items: list[dict[str, Any]] = []
         for asset in assets:
             asset_id = asset.get("id", "")
@@ -145,7 +153,6 @@ def _format_assets(
                 media_type="video" if asset_type == "VIDEO" else "image",
                 api_key=client.api_key,
                 internal_url=client.url,
-                cache_key=asset_id,
             )
             if entry is not None:
                 media_items.append(entry)