fix(e2e): directory-picker race, markdown a11y, variant-picker SSE softening (issue #104 cont.) (#106)

* fix(e2e): fix directory-picker race + markdown accessibility, soften variant-picker SSE assertion

Second iteration against real CI evidence from run 29617520311 (PR #105):

directory-picker still failed after enabling static snapPoints. The mock
server's own request log proved GET /file was still never called, meaning
DirectoryBrowserSheet's onChange never ran enter(). Root cause: the caller
(openBrowser in app/(tabs)/index.tsx) sets startDirectory via setState and
calls sheetRef.current?.expand() synchronously in the same handler. expand()
kicks off a reanimated-driven animation whose onChange fires before React
commits the re-render that would give the child the new startDirectory prop,
so the first onChange(index=0) captured the stale initial `null` and set
wasOpen=true — permanently blocking every later onChange for that open.
Mirrored startDirectory into a ref (updated inline on every render) so
handleSheetChange always reads the latest value regardless of which
render's closure actually fires.

diff-scroll still failed even after removing the nested FlatList — but the
new diagnostic screenshot showed the text WAS visually on screen while
Maestro's accessibility-tree-based assertion still couldn't find it for the
full timeout. That matches a real, still-open React Native Android bug
(facebook/react-native#46999, a reopened regression of #28952's fix):
selectable Text inside a FlatList row doesn't get its selectable/accessible
state applied correctly. react-native-marked's base Renderer hardcodes
`selectable` on every plain text node (text/strong/em/del/heading/codespan).
Overrode those in Markdown.tsx's CustomRenderer to render plain (non-
selectable) Text — code content stays copyable via CodeBlock's own Copy
button.

variant-picker: confirmed the model-selection fix worked completely (chip
appears, opens, selects, label updates) and the flow only fails afterward at
the exact same SSE-streamed-reply limitation documented in
activation-positive.yaml (issue #90 mode B — this CI harness's Android
emulator + Node mock + adb-reverse combination cannot deliver more than the
SSE stream's first chunk). Softened the post-send assertion to match
activation-positive's pattern: verify the optimistic local echo
(chat-bubble-user) instead of waiting on the unrenderable-in-CI reply.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* fix(ci): capture maestro hierarchy dumps in debug artifact upload

actions/upload-artifact excludes dotfiles/dot-directories by default, and
maestro's --debug-output nests the actual UI-hierarchy dump under a hidden
.maestro/tests/<timestamp>/ directory — so every activation-e2e run has been
silently uploading only logcat.txt/probe.txt and dropping the one artifact
most useful for diagnosing flow failures (issue #104). Set
include-hidden-files: true on that upload step.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

.maestro/flows/variant-picker.yaml

@@ -21,6 +21,11 @@ name: Variant picker - reasoning-effort chip renders, selects, and still sends
 # NOT render on session open. This flow explicitly opens the model picker and
 # selects the mock provider's model first, which is what actually makes
 # variants available — matching how a real user reaches this chip.
+#
+# This flow does NOT assert on the SSE-streamed assistant reply after
+# sending — see the "Sending a message" comment near chat-send-button below,
+# and activation-positive.yaml's file-level comment, for why (issue #90 mode
+# B: a CI-harness-specific SSE limitation, not an app bug).
 
 - launchApp:
     clearState: true
@@ -98,7 +103,14 @@ name: Variant picker - reasoning-effort chip renders, selects, and still sends
 - takeScreenshot: variant-S4_chip_shows_high
 
 # Sending a message must still work with a variant selected (regression: the
-# variant chip must not break the send path).
+# variant chip must not break the send path). Like activation-positive.yaml,
+# this stops at the optimistic local echo (src/stores/sessions.ts) instead of
+# waiting on the SSE-streamed assistant reply — issue #90 mode B (see
+# activation-positive.yaml's file-level comment) proved that in THIS harness
+# (Android emulator + this Node mock + adb-reverse) the long-lived SSE
+# connection reliably delivers only its first chunk, so the reply never
+# renders here regardless of app correctness. Asserting on it would be
+# asserting on a CI-harness limitation, not real app behavior.
 - tapOn:
     id: "chat-message-input"
 - inputText: "Message with reasoning effort set to high"
@@ -109,14 +121,14 @@ name: Variant picker - reasoning-effort chip renders, selects, and still sends
 
 - extendedWaitUntil:
     visible:
-      text: "Hello from the mock opencode server"
-    timeout: 20000
+      id: "chat-bubble-user"
+    timeout: 5000
 - assertVisible:
-    id: "chat-bubble-assistant"
+    id: "chat-bubble-user"
 - assertVisible:
     text: "Message with reasoning effort set to high"
-# The chip must still read "High" after the round trip (selection persists
-# across a send, it isn't reset by the reply landing).
+# The chip must still read "High" after sending (selection persists across a
+# send, it isn't reset once the message is submitted).
 - assertVisible:
     text: "High"
-- takeScreenshot: variant-S6_reply_received_variant_still_high
+- takeScreenshot: variant-S6_message_sent_variant_still_high