Recheck current main before every client-refresh mutation #5877

Problem

#5666 decided that every forward mutation of a Longhorn V2 run checks current main immediately before it. On main at 0b2272f, the client refresh checks only twice: before moveForRefresh and after it (hugepages.go L105, L112). Between those checks, the cordon and every eviction attempt, retries included, run without a recheck (refresh_moves.go L307–L405). If main moves while a replacement Pod becomes ready, the old source can still evict another Pod. This was found by reading the code; no run has shown it.

Acceptance criteria

• The refresh checks current main against its own source immediately before each forward mutation: the cordon, every eviction attempt including retries, and the kubelet restart.
• On a moved main, the run issues no further forward mutation. If no kubelet restart was attempted, its deferred, ownership-checked cordon release still runs, as it does today, which returns the worker to its state before the run. After a restart attempt, the cordon stays for adoption by a new main dispatch (README L56–57, L229–231).
• Tests cover main moving between two evictions, between an eviction retry and the next attempt, and just before the kubelet restart. In each case no further forward mutation runs, and the release matches the rule above.
• scripts/migrate-longhorn-v2/README.md says how to dispatch when main is busy:
  • dispatch only with an empty platform merge queue, and hold agent-lane platform enqueues for the run;
  • prefer 00–06 UTC, away from the backup window;
  • expect a hold, and resume it by adoption, never by deleting the journal or cordon.

The benchmark side needs no change here; its recovery and dispatch integration stay in #5665.

Follow-up of #5666.

🤖 Generated with Claude Code