test(e2e): increase timeout for repeated affinity migration

[danilrwx]

Description

Increase the timeout for the repeated affinity migration check in the legacy affinity/toleration e2e test.

The test updates vm-c placement from anti-affinity back to affinity and waits for a new migration to start. In the failed NFS run, the second migration reached PreparingTarget, created the target pod, but did not expose a fresh startTimestamp within the previous 90-second timeout.

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

The test is flaky on slower environments such as NFS-backed clusters where repeated live migration preparation may take longer than the generic legacy timeout.

This change makes the test wait long enough for the second migration to actually start instead of failing early with couldn't wait for the migration to start while the migration is still being prepared.

What is the expected result?

1. Run the legacy affinity/toleration e2e test.
2. Update vm-c from anti-affinity to affinity during the test.
3. Verify the test waits for the repeated migration long enough and does not fail prematurely on slow environments.

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: test
type: fix
summary: "Increase timeout for repeated affinity migration in the legacy affinity/toleration e2e test."
impact_level: low