<!-- Thank you for making a contribution! Here are some tips for you:
- Use Conventional Commits for the PR title: `type(scope): description`
  - Types: feat, fix, docs, style, refactor, perf, test, build, ci, chore
  - Scopes are not an exhaustive list — pick the most specific scope for the change and extend the list when a genuinely new area appears. Examples:
    - System components: dashboard, platform, operator, cilium, kube-ovn, linstor, fluxcd, cluster-api
    - Managed apps: postgres, mariadb, redis, kafka, clickhouse, virtual-machine, kubernetes
    - Development and maintenance: api, hack, tests, ci, docs, maintenance
  - Breaking changes: append `!` after type/scope (`feat(api)!: ...`) or add a `BREAKING CHANGE:` footer
- If it's a work in progress, consider creating this PR as a draft.
- Don't hesistate to ask for opinion and review in the community chats, even if it's still a draft.
- Add the label `backport` if it's a bugfix that needs to be backported to a previous version.
-->

## What this PR does


### Screenshots

<!-- REQUIRED for UI changes: attach screenshots or screen recordings demonstrating
the visual impact of your changes. PRs with UI changes without screenshots will not be merged. -->

### Release note

<!--  Write a release note:
- Explain what has changed internally and for users.
- Start with the same `type(scope):` prefix as in the PR title
- Follow the guidelines at https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md.
-->

```release-note

```