Stop an in-flight poll undoing a cursor reset

[mpretty-cyro]

The bug

A group's poll cursor (its per-snode last hashes) is reset so this device re-fetches the group's
history. If a poll of that swarm is in flight when the reset happens, it finishes afterwards and
writes its newest hash back as the cursor. That undoes the reset, and the history is never fetched.
The window is one poll round trip. It is real because promotion arrives in our own swarm while the
group is polled on its own schedule.

pollNodeForKey already had a check for this, but it could never fire. It tested the
{ namespace, lastHash } objects, which are always truthy, instead of their lastHash:

namespacesAndLastHashes.some(m => m) && namespacesAndLastHashesAfterFetch.every(m => !m)

Fixing it to read lastHash would still miss two cases:

• a reset of a cursor that was already empty, where both reads are empty;
• a reset that lands while the cursor write is itself in progress.

Reset sites

All three go through SwarmPolling.resetLastHashesForConversation, which is where the guard sits,
so a future caller is covered too:

• Promotion to admin: handleGroupUpdatePromoteMessage, handleGroupV2Message.ts:621.
• Recreating a missing group dump: createInitialDumpsMissingForGroups,
  libsession_utils.ts:735.
• Deleting a group with clearFetchedHashes: ConvoHub.deleteGroup,
  ConversationController.ts:442. It is reached from:
  • leaving a group (useShowLeaveGroup.ts);
  • the group being removed from user groups (configMessage.ts:706);
  • being kicked (handleLibSessionMessage.ts:60);
  • a group missing from the wrapper after a poll (swarmPolling.ts:825);
  • a group destroyed after a merge (SwarmPollingGroupConfig.ts:58);
  • metaGroups.ts:283.

The guard

• Each reset bumps a per-conversation count, synchronously, before its first await.
• A poll takes the count when it starts. If the count has changed by the time its fetch returns,
  it writes no cursor and drops its results.
• The count is checked again before each part of the cursor write (database and in-memory cache).
  A reset landing during those awaits is therefore not undone either.

Dropping the in-flight poll's messages keeps the discard the old check intended. The next poll
fetches them again from the start, and seen-message dedupe absorbs the overlap.

A reset that happens after the poll's cursor write has landed is outside this fix.

Testing

SwarmPolling_cursorReset_test.ts drives pollOnceForKey with both polled snodes' retrieves held
open, resets the cursor, then lets them complete. The cases:

• the cursor was already empty before the fetch;
• the cursor was set before the fetch;
• the reset lands during the cursor write;
• a control with no reset, where the poll writes its cursor as before.

Each reset case asserts that no cursor was written and that the next poll asks from the beginning.

957 passing, 0 failing, tsc 0 errors, eslint clean at 7e87828d4.

Mutation results:

guard removed	result
all of it	3 failing
the upstream value comparison, with lastHash fixed, in place of the count	2 failing (the empty-cursor and mid-write cases)
only the checks inside the cursor write	1 failing

[Bilb]

lgtm