[Bug]: Android: a share an interrupted import reserved shows "already reserved for another project draft" on every launch #27736

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/mobile

Steps to reproduce

On a phone this follows an import that was interrupted after it reserved the shared item for a project, for example by the app being closed mid-import. The exact interruption is hard to time by hand, so these steps recreate the state it leaves behind (a debug build lets run-as write the app's inbox):

1. Pair the app with an environment that has at least two projects, A and B, where A is the one a new draft falls back to (the first listed, or the last chosen).
2. Force-stop the app. Save a share reserved for project B in the app's inbox, files/incoming-shares/<id>.json:
   {"schemaVersion":1,"id":"repro-share-1","createdAt":"…","destination":{"environmentId":"<env>","projectId":"<B>"},"text":"shared text","attachments":[],"warnings":[]}
3. Open the app.

Expected behavior

The share opens in a draft for project B, the project it was reserved for, and is imported. The project picker already does this when it resumes a reserved share.

Actual behavior

"Could not import shared content: The shared content is already reserved for another project draft." appears with Cancel import and Retry. Retry shows the same alert. Cancel import closes the draft but leaves the share in the inbox, so the alert comes back on every launch. The only way to clear it is to clear the app's storage.

Impact

Minor bug or occasional failure

Version or commit

T3 Code 2.2.0 (Android). Reproduced on a dev build of main @ 5b357b3.

Environment

Pixel 11 Pro XL, T3 Code 2.2.0. Reproduced on an Android 36 emulator (Pixel 9, arm64) with a dev build of main against a local dev server.

Logs, stack traces, or screenshots

Cause, from the source at 5b357b3:

1. On launch, presentPendingIncomingShare opens the pending share's draft with only its id (IncomingShareProvider.tsx#L274), even when the share has a destination reservation.
2. With no route project, the draft selects the environment's first or last-chosen project (new-task-flow-provider.tsx#L326) and builds the import target from it (NewTaskDraftScreen.tsx#L306).
3. reserve rejects a destination that differs from the saved one (incoming-share-inbox.ts#L148).
4. A failed reserve never sets reservedFor (incomingShareImport.ts#L207), so Cancel import has no reservation to release (#L335) and the share stays reserved.

The project picker resumes a reserved share in its own project (NewTaskRouteScreen.tsx#L274), but the launch path opens the draft directly and skips it. #25744 and #25793 moved presentation and imports to their current places.

Logged on the emulator (temporary console.warns), main: the draft has no route project, selects the fallback project "server", and reserves the share for it while the share is reserved for Bravo:

[repro] draft   {"initial":{"cloning":false},"selected":{"title":"server",…},"target":{"projectId":"ac3b9f10-…"}}
[repro] reserve {"destination":{"projectId":"ac3b9f10-…"},"shareId":"repro-share-1"}

Reproduced on two cold starts, plus Retry failing and Cancel import leaving the share in the inbox.

Workaround

None in the app. Clearing the app's storage removes the stuck share, but also its pairings and drafts.

Model: Claude Opus 5.5 via Claude Code, in T3 Code.