[Yarden-zamir]

Merges 11 new pingdotgg/t3code main commits (head c1876b5) into fork main. node scripts/fork-adopted-prs.ts sync: 0 adopted pull requests.

🔴 Update channels: pingdotgg#26288 "switch your whole fleet between Stable and Nightly" overlaps the fork's update system. Fork machines keep updating from fork releases:

• selfUpdate.ts: forkUpdateTarget stays; upstream's track-crossing guard runs on the version that actually installs.
• useUpdateEverything.ts: useForkReleaseInstallable stays; upstream's channelSwitch branches are in.
• SidebarUpdatePill.tsx: installLocalUpdate({ unattended, expectedVersion }); a pinned version skips the fork newer-release check.
• Left out: the desktop "Update track" switch (Settings > About), hidden with SHOWS_DESKTOP_UPDATE_TRACK = false in ForkSettingsPanelRows.tsx. It targets npm t3@latest / t3@nightly (upstream builds), and the fork publishes only nightly releases, so "latest" would stop updates. Upstream's code stays merged and typed. Noted in docs/fork/features.md (Fork releases > Limits).

Other conflicts (fork kept + upstream taken): cliRelease.ts (fork repository constant + channel helpers), ipc.ts/preload.ts (fork check-before-install + installUpdate(expectedVersion)), DesktopUpdates.ts (fork install + release floor), ScheduledTaskService.ts (upstream sendBound retry + fork terminal-thread refusal), thread-list-v2-items.tsx, Sidebar.tsx, useThreadActionMenu.ts (fork items + "Turn into project"), ThreadDetailsPanel.tsx (upstream card options + fork pins button), AppearanceSettingsPanel.tsx, SettingsPanels.tsx (fork idle-install prompt + upstream fleet state), pnpm-lock.yaml (lockfile.py).

Extra fixes: ScheduledTaskService.test.ts upstream test gets ServerSettings.layerTest(); ForkTerminalThreadScreen.tsx passes an empty usage prop.

Taken in full: thread details card options (pingdotgg#26904), turn a No project thread into a project (pingdotgg#26767), undo notice in the sidebar footer (pingdotgg#26874), Labs limits toggle (pingdotgg#26859), Antigravity changes, Electron 44.10.0 (pingdotgg#26348), agent mistakes fail early (pingdotgg#26167; no fork file flagged).

Checks: checks.py passes. fork_tests.py: 287 of 287 files. Web sidebar/settings/menu/update/details: 369 tests. Desktop src/updates: 83. Server cloud/desktopUpdate/migrations/forkReleases: 175 (+1 existing skip). Budget unchanged.

[Yarden-zamir]

🤖 Review of the upstream merge (head 2087f62). Verdict: approve. Nothing blocks the merge. The update path keeps fork releases.

Update path (checked)

• Desktop app: the offerable check and the release floor in DesktopUpdates.ts still accept only builds on the running app's track. Fork builds are nightly and the default channel comes from the app version. allowDowngrade stays off outside a track switch. The idle-install prompt (__root.tsx:227) and the newer-release check (SidebarUpdatePill.tsx:173, SettingsPanels.tsx:230) still run. Only UpdateTrackSwitchDialog passes expectedVersion, and only that dialog skips the newer-release check.
• Track switch: UpdateTrackSwitchDialog and useUpdateEverything(…, channelSwitch) are the only senders of channel. Both are reachable only through SettingsPanels.tsx:322, which SHOWS_DESKTOP_UPDATE_TRACK = false closes. Mobile, ForkUpdates (machines_command installUpdate, forkAutoUpdate) and the fleet "update everything" flow never send channel.
• Server self-update: forkUpdateTarget runs first, then the crossing check runs on the version that installs. An upstream Stable request from the store app maps to the newest fork nightly, so the check does not refuse it. An upstream version with no fork release still fails at download from the fork repository. It cannot install an upstream build.

Findings (non-blocking)

1. apps/web/src/components/settings/settingsSearch.ts:1341: on desktop, search still lists "Update track". The result opens About, but that page has no such row. Hide the result when isElectron && !SHOWS_DESKTOP_UPDATE_TRACK.
2. apps/server/src/cloud/selfUpdate.ts:113 and apps/web/src/components/ServerUpdateAction.tsx:47: the refusal text says "Switch tracks from Settings → About → Update track". The fork desktop app hides that row. This text shows only for a real crossing, for example an upstream server or a fork server with no newer release, so the impact is small.
3. One-way state: before this merge, the fork showed a plain Stable/Nightly select. A desktop app that a user set to Stable (updateChannelConfiguredByUser: true, updateChannel: "latest" in desktop-settings.json) gets no fork updates, and this merge removes the only way back. This Mac has no saved channel, so it is not affected. If another fleet machine has one, edit the file, or let the fork ignore a saved channel that does not match the app's track.
4. No test covers the new order in selfUpdate.ts:194 (map to a fork release, then check for a crossing). One row in selfUpdate.test.ts would guard the store app path: a nightly server, a Stable request, and a newer fork nightly should install without a refusal.

Checks run

• server src/cloud src/desktopUpdate src/fork/forkReleases.test.ts src/fork/ForkUpdates.test.ts: 167 passed, 1 skipped
• desktop src/updates src/settings: 107 passed
• shared cliRelease: 3 passed
• contracts: 199 passed
• web unit and browser settings sidebar ServerUpdateAction desktop useThreadActionMenu: 496 of 497 passed. TelemetryExportSettings "does not resend a field…" timed out once under load and passed alone. The merge does not touch that file.
• shared_files.py: 51 files changed on both sides. I spot-checked the auto-merged update files (releaseNotes.ts, DesktopAppSettings.ts, preload.ts, ipc/methods/updates.ts, DesktopAppUpdate.ts) and clientRpcPermissions.ts. I found no silent break. Upstream main moved on to e6ca170 after this merge. That needs no action for this PR.