feat(swift-ios): arrange threads with drag handles

[saphid]

SwiftUI could not arrange threads across Pinned, Active, Snoozed, and Settled like React Native.

Open Arrange threads from a thread menu. Drag a handle to reorder Pinned or Active, move between them, settle a thread, or bring a snoozed or settled thread back. VoiceOver actions provide the same supported moves. Normal thread holds still open menus. The Home swipe and scrolling implementation is unchanged.

This updates the existing order-key implementation against the latest SwiftUI branch. Order stays shared across environments and clients. Each write goes to the thread's owning server. The planner reserves hidden keys and rejects unsupported, disabled, or disconnected writes before starting a move. Failed writes retain confirmed keys and refresh every touched environment.

Verification:

• Swift syntax parsing and git diff --check pass.
• Focused coverage includes command payloads, capability decoding, key generation, multi-environment ordering, cross-section lifecycle changes, stale targets, and unavailable servers.
• Native CI builds the app and passes 708 Swift Testing tests plus 266 XCTest cases, with one skip and no failures, at 3b96928191.
• Macroscope correctness and the remaining required checks pass on that commit.
• Current UI interaction checks and evidence remain with the main integration session. No current visual result is claimed here.

Original order-key work is retained from this PR. Updated in Codex.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a substantial iOS thread-arrangement workflow with new UI, drag/drop state management, cross-environment reorder commands, lifecycle mutations, and changes to existing sorting behavior. Unresolved findings also report a possible compile issue and stale sheet presentation state, so the scope and runtime impact require human review.

Not approved because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

[saphid]

Addressed the Macroscope findings on the latest push (bc2af43d42):

• Disconnected environments in planning — fixed: movePlanner/moveOptions now take the connected environment set, so rows from a dropped server stay as ordering anchors but are never assigned keys, and a disconnected row offers no Move actions.
• Section read after await — fixed: moveThread captures the pinned/active section before the call, so a mid-flight pin/unpin cannot misapply confirmed keys.
• Partial reorder dropped confirmed writes — fixed: a half-landed spread rewrite now throws FeatureThreadMovePartialError carrying the confirmed assignments; the caller applies them before surfacing the underlying error.
• orderKeyBetween(nil, "ma") returning nil on pin — intentionally unchanged: this matches the React Native reference (pinOrderKeyBetween(null, firstKey) ?? undefined). Order-key generators never emit a trailing minimum digit, so this path only triggers on already-corrupt server data, in which case both clients fall back to a keyless pin sorted by creation order.

[saphid]

Note for reviewers on the Macroscope findings re-flagged against the drag-and-drop head (2d2c40b9):

• FeatureRootModel.swift moveThread section-after-await — Macroscope itself marks this "No longer relevant as of bc2af43"; that code path was removed entirely in the drag rework (reorderThread takes the section as a parameter).
• NativeFeatureClient.swift orderKeyBetween(nil, firstKey) returning nil on a corrupt earliest key — intentionally unchanged, same rationale as before: it matches the React Native reference (pinOrderKeyBetween(null, firstKey) ?? undefined), and order-key generators never emit a trailing minimum digit, so the path only triggers on already-corrupt server data. Both clients then fall back to a keyless pin sorted by creation order.

[macroscopeapp]

🟡 Medium

t3code/apps/swift-ios/Features/Workspace/WorkspaceView.swift

Line 641 in ca5fd6d

renamingThread = nil

Incoming navigation requests leave showingThreadArrangement set, so the workspace changes behind the still-present ThreadArrangementView and .newTask requests cannot present NewThreadView until the unrelated sheet is dismissed. Reset showingThreadArrangement in dismissTransientPresentations() along with the other transient presentation state.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/swift-ios/Features/Workspace/WorkspaceView.swift around line 641:

Incoming navigation requests leave `showingThreadArrangement` set, so the workspace changes behind the still-present `ThreadArrangementView` and `.newTask` requests cannot present `NewThreadView` until the unrelated sheet is dismissed. Reset `showingThreadArrangement` in `dismissTransientPresentations()` along with the other transient presentation state.