gate thread-muting reply cycles on composer actually closing

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

__e2e__/flows/thread-muting.yml

@@ -99,12 +99,17 @@ appId: xyz.blueskyweb.app
 - inputText: "Reply 2"
 - tapOn:
     id: "composerPublishBtn"
-# Wait for the composer to close and the thread reply button to return before
+# Wait for the composer to actually close before opening it again. replyBtn
-# opening the composer again. The replyBtn is effectively always present on this
+# stays in the accessibility tree behind the open composer sheet, so waiting on
-# screen, so waiting on its visibility alone does not gate on the composer close
+# its visibility returns immediately and does not gate on the close animation or
-# animation or the author-feed re-render that follows a post. Without letting
+# the author-feed re-render that follows a post - the next replyBtn tap then
-# those settle, the next replyBtn tap fires mid-transition and is swallowed, so
+# fires mid-transition and is swallowed, so the composer never opens. Gate on
-# the composer never opens. Wait for the button, then for animations to end.
+# the publish button disappearing (the composer is gone), then confirm the
+# reply button underneath is back and let animations settle.
+- extendedWaitUntil:
+    notVisible:
+      id: "composerPublishBtn"
+    timeout: 15000
 - extendedWaitUntil:
     visible:
       id: "replyBtn"
@@ -122,7 +127,13 @@ appId: xyz.blueskyweb.app
 - inputText: "Reply 3"
 - tapOn:
     id: "composerPublishBtn"
-# Wait for the composer to close and the thread to settle before signing out.
+# Wait for the composer to actually close before signing out. As above,
+# replyBtn stays visible behind the sheet, so gate on the publish button
+# disappearing first, then confirm the reply button underneath has returned.
+- extendedWaitUntil:
+    notVisible:
+      id: "composerPublishBtn"
+    timeout: 15000
 - extendedWaitUntil:
     visible:
       id: "replyBtn"