SSCAN returns incorrect results if items are removed from the set between executions

Nobody has claimed this yet.

### Describe the bug

If you perform an SSCAN and get a cursor, then remove items from the set, then do another SSCAN using the previously returned cursor you can get incorrect results. It looks like this is because the returned cursor is simply the position in the set for the last entry returned, so if the size of the set changes it refers to the wrong position.

### Steps to reproduce the bug

1. Create a set with 2 entries: `SADD test-set entry-a entry-b`
2. Perform an SSCAN: `SSCAN test-set 0 COUNT 1` - this returns cursor `1`
3. Remove the first entry: `SREM test-set entry-a`
4. Perform another SSCAN using the previously returned cursor: `SSCAN test-set 1 COUNT 1` - this returns no results instead of the expected `entry-b`

### Expected behavior

Using the cursor returned before the set was modified should return the remaining set entries - this is the behaviour in other Redis-like datastores.

### Screenshots

_No response_

### Release version

_No response_

### IDE

_No response_

### OS version

_No response_

### Additional context

_No response_

No source file or test is named. Start by reproducing the issue with the listed SADD, SSCAN, and SREM commands, then trace Garnet's SSCAN handling and cursor state. Done means continuing from the returned cursor after removing entry-a still returns entry-b, with coverage for the reproduction sequence.

Written by the indexing model from the issue text.