PROD-9829: Fix comment video thumbnails and low-res thumbnail regeneration

[rezwan-buddyboss]

PROD link: https://buddyboss.atlassian.net/browse/PROD-9829

This ticket bundles two separate reported bugs; both are fixed in this PR.

Issue 1 — comment video attachments lose their thumbnail after posting

Uploading a video to a top-level activity post generates and keeps a thumbnail correctly. Uploading the same video as an activity comment attachment shows the thumbnail preview during upload, but once the comment is submitted, the thumbnail disappears and the default placeholder shows instead — reloading the page doesn't fix it. The video itself plays fine; only the thumbnail is lost.

Root cause

Two separate problems compounded:

1. bp_video_add_generate_thumb_background_process() explicitly excluded privacy === 'comment' videos (alongside forums/message) from the FFmpeg-based background thumbnail job, so comment attachments never got a server-side regeneration fallback the way post attachments do.
2. The real trigger, though, is a client-side race condition. bp.Nouveau.getVideoThumb() captures a video frame to a <canvas>/<img> fully asynchronously, with no completion callback. The top-level post composer already accounts for this — it polls for a dz-has-thumbnail/dz-has-no-thumbnail class signal before reading the captured image. The comment composer's upload success handler never got that same wait: it read $( file.previewElement ).find( '.dz-video-thumbnail img' ).attr( 'src' ) immediately, before the async capture had necessarily finished, so it frequently pushed an empty/undefined preview into the comment's video data.

Fix

• Removed 'comment' from the exclusion array in bp_video_add_generate_thumb_background_process() (src/bp-video/bp-video-functions.php:1034), so comment attachments get the same background-job fallback post attachments already have.
• Ported the post composer's wait pattern into the comment composer (src/bp-templates/bp-nouveau/js/buddypress-activity.js): the video data object is still pushed synchronously (so comment-content validation sees it immediately and doesn't block submission), but if js_preview came back empty, a setInterval polls for the dz-has-thumbnail/dz-has-no-thumbnail class and backfills js_preview on that same object (by reference) once the async capture actually finishes.
• buddypress-activity.min.js was hand-patched to match, rather than regenerated via grunt uglify — this checkout has no node_modules installed and a known peer-dependency conflict blocks npm install here. This should be regenerated via a proper grunt build during review rather than trusted long-term as a hand-patch.

Issue 2 — low-resolution videos re-trigger thumbnail regeneration on every page load

When a source video's dimensions are smaller than a registered thumbnail size (e.g. bb-video-poster-popup-image), that size can never be generated. Reported behavior: instead of failing once and remembering that, the system re-attempts generating that size on every single page render, and reportedly multiple times per request — degrading feed load time in proportion to how many small videos are on the page. Not reproduced locally, but the code-level defect the ticket points at is real and independently confirmed by reading the function.

Root cause

bb_video_get_attachment_symlink() calls bp_video_regenerate_attachment_thumbnails( $attachment_id ) — a full wp_generate_attachment_metadata() regeneration — every time a requested size's file doesn't already exist (! $file), with no memory of whether that size has already been tried and failed. For a size the source video is simply too small to ever produce, every single page load that touches this attachment re-runs the full regeneration for that size, forever.

Fix

Added a _bb_video_thumb_unavailable_sizes postmeta array, following the starting point the ticket itself suggested. Before calling bp_video_regenerate_attachment_thumbnails(), the requested $size is checked against that array and skipped if already recorded. After a regeneration attempt, if the file still doesn't exist, the size is added to the array so no future request re-attempts it. A size only ever costs one real regeneration attempt per attachment; every request after that is a cheap postmeta lookup.