Fix removed workspace resurrecting via serialization race (#52035)

In `remove_workspace`, the removed `Entity<Workspace>` could still have
a pending `serialize_workspace` throttle timer (200ms). When that timer
fired, `serialize_workspace_internal` would write the old `session_id`
back to the DB — undoing the removal. On next restart, the workspace
would reappear.

The race window opens whenever any state change (worktree change,
breakpoint change, etc.) triggers `serialize_workspace` within 200ms
before `remove_workspace` is called.

**Fix**: Before the DB cleanup task, `update` the removed workspace
entity to:
1. `session_id.take()` — so any in-flight serialization writes
`session_id: None`
2. `_schedule_serialize_workspace.take()` — cancel the pending throttle
timer
3. `_serialize_workspace_task.take()` — cancel any actively running
serialization task

This mirrors what `remove_from_session` already does (clearing
`session_id`), but `remove_workspace` was missing it.

Release Notes:

- Fixed a bug where a removed workspace could reappear on next launch
due to a serialization race.
4049a4c914Richard Feldman committed on 3/23/2026, 3:46:32 PM· committed by GitHubparent5d9e8a2
1 file changedLine totals unavailable