[Bug]: Mobile current-checkout threads store a null branch and cannot show PR badges

[Zeus-Deus]

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

1. In the native mobile app, create a thread in a Git repository.
2. Leave the default workspace mode on the current/local checkout and do not explicitly choose a branch in the branch picker.
3. Start the task.
4. Create or let the agent create a branch and an open pull request for the work.
5. Return to native mobile Thread List v2.

Expected behavior

The thread should retain enough branch/change-request identity to show the matching PR badge once an open PR is discovered, just as a thread created with explicit branch metadata can.

At minimum, a new current-checkout thread should not persist branch: null merely because the user accepted the already displayed current-checkout default without opening the branch picker.

Actual behavior

The mobile creation flow can persist branch: null. The row's PR hook refuses to subscribe or render any PR when that field is null, so an existing open PR is invisible on the thread row.

This produces a misleading asymmetry: threads with stored branch metadata can show their PR badge, while a mobile-created current-checkout thread may never show one despite its repository and PR being valid.

Impact

Minor bug or occasional failure

Version or commit

Source inspected at 9146ed2f; behavior observed in the current iOS app with T3 server 0.0.31.

Environment

Native iOS app, Thread List v2, GitHub repository on a connected environment.

Notes

No private screenshot, repository name, branch name, or PR number is attached.

Relevant source path:

• apps/mobile/src/features/threads/new-task-flow-provider.tsx
  • workspaceMode defaults to "local".
  • selectedBranchName defaults to null unless a branch was explicitly written into workspaceSelection.
  • The automatic preferred/current-branch selection effect runs only for workspaceMode === "worktree".
  • Queued creation serializes branch: workspaceSelection?.branch ?? null.
• apps/mobile/src/features/threads/NewTaskDraftScreen.tsx
  • Online creation passes branch: selectedBranchName, which remains null for an untouched local/current-checkout default.
• apps/mobile/src/state/use-thread-pr.ts
  • Does not subscribe when thread.branch === null.
  • Returns null unless status.refName === thread.branch.

A narrow first fix is to resolve and serialize the current local ref when the default local checkout is used. Please also consider the follow-on case where an agent switches branches after creation, since the PR matcher requires exact equality and branch identity can become stale.

Suggested regression coverage:

1. New local/current-checkout task with an untouched branch control serializes the current local ref, not null.
2. Explicit branch selection continues to win.
3. Detached HEAD and non-repository projects remain safe and do not fabricate a branch.
4. A matching live PR becomes visible through useThreadPr().

Related but not duplicate:

• [Bug]: Worktree threads lose their PR badge once the agent switches branches inside the worktree #4831 covers a stored worktree branch becoming stale after an agent switches branches.
• [Bug]: Worktree threads can miss existing pull requests #4106 covers worktree PR discovery/polling.
• [Bug]: Settled local thread unsettles and loses merged PR# when switching back to main for pull / new branch #4752 covers settled local threads losing prior PR state after the shared checkout changes branches.

This report is the native-mobile creation path storing no initial branch when the current-checkout default is accepted implicitly.