fix(vm): handle FailedMapVolume in pod volume error detection

[eofff]

Description

Added handling for one more pod volume warning reason (FailedMapVolume) and unified volume-error reason checks in the VM controller.

Changes:

• added ReasonFailedMapVolume constant in volumeevent_watcher.go;
• introduced IsVolumeErrorReason(reason string) helper to keep reason filtering in one place;
• replaced duplicated checks in watcher predicates/handlers and in VM lifecycle error extraction with the new helper.

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

Previously, VM pod volume errors were recognized only for FailedAttachVolume and FailedMount.
In some failure scenarios Kubernetes emits FailedMapVolume, so the controller could miss relevant warning events and return less informative VM error status.
After this change, all key volume-related warning reasons are processed consistently, so users get clearer and more complete diagnostics when VM startup fails due to volume issues.

What is the expected result?

1. Create/reproduce a VM startup issue where pod events include FailedMapVolume (or existing FailedAttachVolume / FailedMount).
2. Verify that the event is picked up by volume event watcher.
3. Verify that VM status/lifecycle returns a VMPodVolumeError with the correct Reason and Message.

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: vm
type: fix
summary: "VM pod volume error handling now includes FailedMapVolume and surfaces more complete pod volume diagnostics."