fix(desktop): keep fresh pin/unpin actions from being undone by pin sync

[Yoki-cmd]

Symptom

On the desktop app, three user-visible failures in the pinned-sessions feature, all in apps/desktop/src/store/session-pin-sync.ts:

1. Pinning a session silently fails — the session never moves into the pinned section (or moves and is instantly removed).
2. Unpinning silently fails — a pinned session stays pinned no matter how many times the user clicks 取消置顶.
3. Pinning a second session right after the first undoes the first — the earlier pin is dropped from the pinned section.

Root cause

reconcile() runs the pull pass (pullRemotePins) before the push pass, and unconfirmed only guards writes that are already in flight. Each fresh local write (pin or unpin) has a window where the sidebar row still carries the pre-write server value and the PATCH has not been sent or acked:

• Window 1 (fresh pin): pinSession → set → reconcile runs synchronously; the row still says pinned=false and the PATCH hasn't been sent, so the pull pass reads the new local pin as stale and removes it.
• Window 2 (fresh unpin): the row still says pinned=true, so the pull pass re-adopts the pin the user just removed.
• Window 3 (post-ack): writePin clears the unconfirmed guard on the PATCH ack, but the row keeps its old pinned value until the WS row update lands. The next reconcile (e.g. the user pinning a second session) then reads the stale row as the server disagreeing and removes the confirmed pin.

Fix

• Track the pinned set as of the last reconcile (lastSeen). Ids added since then are fresh pins — register them in pending before the pull pass and skip the pull's undo branch for them. Ids removed since then are fresh unpins — skip the pull's adopt branch for them (freshlyUnpinned).
• On the PATCH ack, refresh the row's pinned field in $sessions so the pull pass never reads our own confirmed write as stale.
• Boot pins (seeded from localStorage at the first reconcile) stay subject to server authority in both directions.

The pre-existing pull pass behavior — adopting remote pins, dropping stale local pins the server reports unpinned, deferring pins until their row loads — is unchanged and still covered by the existing suite.

Tests

• apps/desktop/src/store/session-pin-sync.test.ts: added 3 tests reproducing each fresh-write window (stale pinned=false page before the pin PATCH is sent; stale pinned=true page before the unpin PATCH is sent; sequential pin-pin with the first row still stale). All 14 tests in the file pass; the existing 11 remote-pull tests are untouched.
• Full src/store suite: 597 passed.

[teknium1]

Thanks for the focused regression coverage. The premise is confirmed on current main: reconcile() calls pullRemotePins() before local push bookkeeping at apps/desktop/src/store/session-pin-sync.ts:102, while the pull can mutate local pins from stale row state at lines 84-91. This change fences fresh local additions/removals before that pull (apps/desktop/src/store/session-pin-sync.ts:128-149 in the PR) and refreshes the matching cached row after an acknowledged PATCH (lines 52-64).

A concurrent maintainer-authored alternative exists in #75973 (9cc3f515629dcf8287ba7ffb237014dbb24d4a29), but it is not on current main; this PR remains a valid fix candidate rather than an implemented-on-main duplicate.

Automated hermes-sweeper review.

[jamesconnors]

Independent reproduction and validation from a macOS ARM64 Hermes setup using Desktop as a thin client against a remote gateway:

• User-visible symptom matched this PR exactly: both the session-row context-menu Pin action and Shift-click reached the shared onPin() callback, but the pin disappeared immediately.
• On current main, a loaded row with pinned: false is pulled before the local push pass, so the optimistic pin is removed before PATCH pinned=true starts.
• I independently wrote the same production-shaped regression first (row(..., { pinned: false })) and observed it fail with expected [] to include 'optimistic'.

I then checked out this PR at 1ee86bea0 in an isolated worktree, installed its exact lockfile dependencies with Node v22.23.1, and ran:

• npm test -- --project ui src/store/session-pin-sync.test.ts — 14/14 passed
• npm run test:ui — 3,234/3,234 passed
• npm run typecheck — passed
• npx eslint src/store/session-pin-sync.ts src/store/session-pin-sync.test.ts — passed
• git diff --check HEAD^ HEAD — passed

The additional post-ack/sequential-pin case is important. A simpler push-before-pull reorder fixes the first click but can still lose a confirmed pin after unconfirmed clears and before the cached row catches up; this PR explicitly covers that window.

One non-blocking documentation nit: the module header still says the whole local pin set is re-asserted at boot (session-pin-sync.ts lines 10–12), while the new lastSeen === null behavior and PR description intentionally make the first server row authoritative. Updating that comment would keep the stated contract aligned with the implementation.

I did not install this branch on the user's live thin client; the evidence above is an independent code-path reproduction plus clean focused/full-suite validation.

[Yoki-cmd]

Thanks for the independent reproduction and the thorough validation — great to have the macOS/remote-gateway path confirmed, and glad the post-ack window test held up.

The doc nit is addressed: the module header now states that the boot re-assertion applies except where a session row already carries an explicit pinned value, which is authoritative from the first reconcile (pushed as a82a223f).

[OutThisLife]

Superseded by #80711. Same pin-sync race (fresh pin/unpin undone by the next reconcile).