fix: Separate the FDv2 source manager scan cursor from the active slot

[kinyoklion]

What this fixes

Review findings against the source manager (#298) that were validated on the end-to-end branch but did not make it into the merged PR.

The core problem: the source manager used one index both as the rotation scan cursor and as "which slot is active." The two move independently — a recovery reset or FDv1-fallback engagement moves the cursor while a synchronizer is still running — so conflating them misreported isPrimarySynchronizer and mis-targeted blockCurrentSynchronizer in those windows.

• The scan cursor (_synchronizerIndex, advanced by nextAvailableSynchronizer, reset by recovery/fallback) is now separate from _activeSlotIndex (the slot of the synchronizer that is actually running, null when none is).
• isPrimarySynchronizer and blockCurrentSynchronizer read the active slot, not the cursor.
• nextInitializer() exhaustion closes the last active source, so a terminal null leaves nothing running.
• engageFdv1Fallback() closes the active source and returns early when no FDv1 fallback slot is configured.
• hasFdv1FallbackConfigured replaces the previous name to say what it checks.
• Class docs state the lifecycle invariant: every transition closes the previously active source.

Testing

New tests pin each behavior: the active slot tracking across recovery resets and fallback engagement, primary detection while the cursor has moved, blocking targeting the running synchronizer, exhaustion closing the final source, and fallback engagement without a configured FDv1 slot. Full package suite passes.

SDK-2186