[mgravell]

Fixes #3260.

A synchronous scan (HashScan, SetScan, SortedSetScan, Keys) that hits SyncTimeout throws RedisTimeoutException and walks away from the task wrapping the in-flight page. When that page later faults (backlog timeout, socket closed), the fault has no observer and surfaces as TaskScheduler.UnobservedTaskException, exactly as reported.

Changes in CursorEnumerable:

• The sync wait observes the orphaned task before throwing the timeout.
• Disposing or resetting an enumerator with a prefetched page in flight now observes that page too (the common break out of a foreach), via a single AbandonPending.
• A disposed enumerator no longer issues one more SCAN when the late page finally arrives.
• Faulted pages surface as their own exception rather than AggregateException, on both the sync and async paths; this matches the rest of the sync surface. Previously the type depended on timing: a fault during the await rethrew the cause, a fault that had already happened (typical with prefetching) came wrapped. Behaviour change, called out deliberately.
• A sync timeout on a scan with no pattern (a single HGETALL etc.) threw NullReferenceException because the enumerator has no Message to report; ExceptionFactory.Timeout now accepts null.

Tests: CursorEnumerableFaultTests, six server-free tests driven by a scripted RedisDatabase. Five of six fail on main for the reasons above; the dispose test was verified to fail with the observation line removed.

Not addressed: calling MoveNext() again after a sync timeout while the earlier page is still in flight double-processes the reply. Pre-existing, separate issue.

No 2.x backport is planned; the fix ships in the current release, which is a non-breaking upgrade from 2.13.x.

Checklist

• I fully and freely contribute this code in accordance with the project license (and am legally able to do so)
• I take responsibility for this contribution's quality and correctness, including any portions produced with AI assistance (see CONTRIBUTING.md).

[mgravell]

👍