retry composer open in thread-muting to survive swallowed taps

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

__e2e__/flows/thread-muting.yml

@@ -87,6 +87,15 @@ appId: xyz.blueskyweb.app
 # (feedItem-by-alice.test) rather than relying on which replyBtn Maestro picks
 # first. This keeps both reply taps deterministic regardless of list order or
 # how many posts have rendered.
+#
+# Even with the close-gating below, the replyBtn tap can land on a recycled list
+# row while the author feed re-renders after a publish, and be swallowed so the
+# composer never opens. Wrapping the tap + open-wait in retry makes opening the
+# composer idempotent: a swallowed tap just re-taps until the publish button
+# appears. A first-try success does not retry.
+- retry:
+    maxRetries: 3
+    commands:
       - tapOn:
           id: "replyBtn"
           childOf:
@@ -115,6 +124,12 @@ appId: xyz.blueskyweb.app
       id: "replyBtn"
     timeout: 10000
 - waitForAnimationToEnd
+# As with Reply 2: even after gating on the composer close, this tap can hit a
+# recycled row during the post-publish feed re-render and be swallowed, so wrap
+# the open in retry to make it idempotent.
+- retry:
+    maxRetries: 3
+    commands:
       - tapOn:
           id: "replyBtn"
           childOf: