* fix(web): preserve manual task selection during archive/delete
When the user archived (or deleted) a task and then immediately picked
another task, the in-flight archive flow would auto-switch to a third
task, clobbering the manual selection.
The shared `removeTaskFromBoard` was honoring the pre-API captured
`wasActiveTaskId` unconditionally. That capture exists to survive the
WS `task.deleted` / `task.updated(archived_at)` handler clearing
`activeTaskId` to null. But it also overrode the legitimate case where
the current store value reflected a user-initiated navigation, so the
equality check still passed and `switchToNextTask` ran.
New guard: switch only when (a) the store still points at the removed
task, or (b) the store has been WS-cleared to null AND the captured
pre-API id matches the removed task. Any other state means the user
moved on — leave them where they chose to go.
* chore(web): tighten null check + no-opts test in use-task-removal
Addresses non-blocking suggestions from claude bot review on #1286.
- Use strict `=== null` in `shouldSwitchAfterRemoval` for consistency
with the surrounding strict-equality comparison.
- Add unit test documenting that a no-opts caller skips the auto-switch
when the WS handler has already cleared `activeTaskId` to null.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
---------
Co-authored-by: Kandev Agent <agent@kandev.dev>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Carlos Florêncio