The ShardVersionMismatch handling currently spans several stages (reading metadata from disk, installing it in memory, and waiting for CSS changes to arrive) and not all of them are cleanly interruptible. We need the whole workflow to be interruptible so that, when interrupted, the ShardVersionMismatch can be restarted from its first step.

Scope: Ensure every stage of the flow (disk recovery, in-memory installation, and any waits on the CSS) checks for and honors interruption, so the thread can be unblocked and the workflow restarted from scratch.

Motivation: This is a first step towards supporting FCV upgrade/downgrade transitions, where in-flight ShardVersionMismatch handling may need to be aborted and retried under the new FCV.