refactor(mobile): share imports run outside the new-task screen#25793

Problem

The new-task draft screen moved an incoming share into its draft from one long useEffect that tracked the import with four state values, five refs, a mount-tracking effect and a useEffectEvent. A second effect left the route once a cancel committed. Cancel and Retry were closures inside that effect, so once the screen unmounted they did nothing.

Change

• apps/mobile/src/features/threads/incomingShareImport.ts: a small state machine for share imports (reserve, attach, consume, with cancel and retry from a failure). Each import is keyed by its draft route's flow key and plain-data target. Reading a target's phase atom starts the import at most once, the same pattern as the new-task branch checkout (new-task-branch-checkout.ts). Alerts and navigation always come after an await, never inside the read.
• IncomingShareProvider.tsx (the share store) owns the instance (incomingShareImports) and its alerts and navigation. It also exports pruneIncomingShareImports. App.tsx's navigation state handler calls the prune next to pruneNewTaskBranchCheckouts.
• NewTaskDraftScreen.tsx works out the import target from render inputs and reads the phase atom. It no longer has an import effect, mount refs or cancellation state.
• I did not rename the store file (the plan suggested incoming-share-store.ts). m-chain-9 also edits it, and a rename would conflict with it.
• I did not port 786's withOpenedNewTaskDraft destination prefill. It belongs to another unit, and main already resumes reserved shares in their own project in NewTaskRouteScreen.

What this improves

• Sync removed: the screen's import effect, its mount-tracking effect, and the effect that called goBack after a cancel. Also gone: four state values, five refs and a useEffectEvent that existed only to coordinate them.
• Durable undo no longer depends on the screen staying mounted (see behavior changes). I make no regression-test claim here: the old path lived inside a screen effect, and I did not add a render test for it.

Behavior changes

• Cancel on a failed import now finishes restoring the draft and releasing the reservation even if the route left in the meantime. Before, Cancel did nothing once the screen had unmounted.
• If the cancel's undo fails after the route left, the "Could not cancel import" alert still appears. Before, it was dropped.
• Cancel undoes the import with the draft store's undoComposerDraftMerge, the same undo outbox recovery uses. On an untouched draft it restores the pre-import draft exactly. If the draft changed since (the user edited or deleted it, or an upload finished on an attachment), it removes only the merged-in text and attachments, matched by id, and keeps the rest. A retried cancel after a failed persist doesn't undo twice. The merged draft is recorded even when the merge published but failed to persist. This matters now that a cancel can finish after the route left. Main replaced the draft with the backup outright.
• restoreComposerDraftSnapshot had no callers left and is removed.
• "Shared content unavailable" is now an inline note under the hero instead of a one-time alert.
• The route is no longer held while a failed import waits for an answer, or while a cancel is undoing. The cancel leaves the route itself when it finishes.
• Imports whose route left the stack are pruned from the navigation state handler. An in-flight import stops before its next durable step, as before. A failed import keeps its retry and cancel until the user answers.
• Start stays blocked while any import for the route is still running, even after the screen stops rendering that import's target (server config dropping on disconnect, or the selected project no longer matching the route's project). This is the same as main, where the lock lasted until the import's finally. The lock reads incomingShareImports.inFlightAtom(flowKey), which counts running attempts per route, abandoned ones included.
• The deleted mount-tracking effect's cleanup also reset appliedInitialProjectKeyRef on unmount. That reset is dropped. It only mattered for an in-place remount (StrictMode or a hidden <Activity>), and the mobile app uses neither for this route. Moving it into the initial-project effect's cleanup would be wrong: that effect re-runs on every selectedProject change, so the route project would override each picker choice.

Effects

• NewTaskDraftScreen.tsx: 8 -> 5
• IncomingShareProvider.tsx: 0 -> 0
• App.tsx: 0 -> 0
• incomingShareImport.ts: new, 0

Verification

• vp test run src/features/threads/incomingShareImport.test.ts: 15 passed. Covers the happy path with file release, a rebuilt atom node running only once, cancel restoring the draft, retrying a failed cancel with the original backup, prune stopping before consume, cancel after the route left, switching drafts abandoning the in-flight import, a route staying in flight after its target stops rendering, a retried cancel keeping a draft edited or deleted after a failed undo, cancel undoing the import after an upload finished, and cancel keeping an edit or deletion made after a merge that published but failed to persist. The harness applies the real undoComposerDraftMergeState. Tests await each attempt's run promise (settled) or the Deferred that marks a step. None of them poll.
• vp run check:changed: every line passes (format, lint, knip 1/2 and 2/2, typecheck, tests). Rebased on main afterwards; main had no changes under apps/mobile since the previous base, and the machine tests still pass.
• Not run on a simulator.

Model: Claude Opus 5.5, Claude Code harness.

🤖 Generated with Claude Code