fix(vmop): restore pending migration reason

[danilrwx]

Description

Restore the dedicated MigrationPending VMOP reason for the earliest migration states, bind it to 0% progress, and treat target scheduling as an active in-progress stage.

Technically, the change updates migration lifecycle handling so that:

• MigrationPhaseUnset and MigrationPending map to vmopcondition.ReasonMigrationPending;
• ReasonMigrationPending keeps VMOP in Pending phase;
• ReasonMigrationPending reports 0% progress;
• MigrationScheduling maps to ReasonTargetScheduling with 2% progress;
• ReasonTargetScheduling keeps VMOP in InProgress phase instead of Pending;
• VM migrating messages distinguish queued migration from active target scheduling;
• internal documentation describes migration reasons, progress values, NotConverging, and failure classification.

Unit tests were updated to cover the restored reason, progress mapping, and the new phase/message semantics.

Why do we need it, and what problem does it solve?

After the migration progress refactoring, the earliest migration states started reporting TargetScheduling with 2% progress instead of the historical MigrationPending state.

This changed the external behavior of VMOP conditions too early: an operation that was still only queued already looked like target scheduling had started. At the same time, once scheduling actually began, VMOP still remained in Pending, which blurred the difference between a queued operation and an actively executing one.

This fix restores the semantic split:

• queued but not yet started -> MigrationPending, Pending, 0%;
• actual scheduling started -> TargetScheduling, InProgress, 2%.

This makes VMOP conditions and VM migration messages closer to the real migration lifecycle and more useful for users and integrations. The internal documentation captures these semantics for future maintainers and reviewers.

What is the expected result?

1. Create or observe a VM migration VMOP before target scheduling begins.
2. Verify that status.conditions[Completed].reason is MigrationPending.
3. Verify that status.phase is Pending and status.progress is 0%.
4. Once scheduling begins, verify that the reason changes to TargetScheduling.
5. Verify that status.phase changes to InProgress and status.progress changes to 2%.
6. Verify that the VM migrating message reports active target scheduling instead of awaiting start.
7. Use docs/internal/vmop_migration_lifecycle.md as the internal reference for reason/progress mapping and failure behavior.

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: core
type: fix
summary: "Restore MigrationPending with 0% progress and treat target scheduling as in-progress for VM migration operations."
impact_level: low