refactor use-tasks to improve cache invalidation/optimistic update flow

[jermzblake]

Real time updates in the task dashboard seem to be inconsistent.
Used AI to debug the issue.

Potential causes:

• The status columns are powered by useTasksByStatus with keys like ['tasks', 'list', { status, page, pageSize }] in status-column.tsx.
• Create: useCreateTask invalidates only the list matching the created task’s status, based on the mutation variables’ status.
• Update: useUpdateTask optimistically removes from the old list for status changes and refetches the destination status list.
• Both flows rely on the mutation payload’s status to decide which list(s) to refetch. If the payload omits status (e.g., server defaults or a form change), the predicate won’t match any active queries and no refetch occurs. That would look like “no real-time updates.”

Key risk points that explain the regression:

• Create invalidation uses only variables.status. If the form doesn’t pass status (or server coerces/normalizes), nothing gets invalidated.
• Update invalidation uses the optimistic payload for new status only, not the server response, and doesn’t refetch the source column (so counts can lag). If the status field didn’t actually change or is missing, invalidation can be skipped entirely.
• For updates, we optimistically remove the task from the old list only when we detect a status change—but previously that detection wasn’t comparing with the previous status, so it could also misfire.

Fixes (safer invalidation, fewer edge-case misses)

• Use the server’s response status when available (fallback to the submitted payload).
• Track the previous status and only treat it as a status change when the value actually changed.
• When a status changes, refetch both the destination and source lists to keep both columns (and counts) consistent.
• If we can’t determine the created status, invalidate all status lists as a safe fallback.