Take the ISO storage from the disk pool when it can hold ISOs

[MickLesk]

Installer VMs (ZimaOS, BlissOS, CachyOS, Umbrel, TurnKey) ask for a storage twice: vm_select_storage for the disks (images content) and vm_select_iso_storage for the ISO (iso content), because Proxmox only attaches ISOs from an ISO-capable storage. When the pool chosen for the disks is ISO-capable it now takes the ISO too, so the second dialog appears only when it has to (for example local-lvm disks with several ISO pools). VM_ISO_STORAGE still wins. The disk dialog says it is for the disks.

New case in tests/vm-iso-storage.sh (22 pass).

[github-actions]

Try this branch

The engine and the scripts resolve independently, so a production script can
be run against the engine from this PR by setting one variable:

COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/community-scripts/core/fix/iso-storage-reuse \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/debian.sh)"

Swap ct/debian.sh for whatever exercises the change.

This PR touches pve/, so it needs a Proxmox VE host.

Run a script from a fork as well

curl -fsSL https://raw.githubusercontent.com/community-scripts/core/fix/iso-storage-reuse/tools/run.sh |
  bash -s -- https://raw.githubusercontent.com/YOU/DevScripts/your-branch ct/debian.sh \
             https://raw.githubusercontent.com/community-scripts/core/fix/iso-storage-reuse

Note that run.sh is reached through a pipe, so the script it starts inherits
an exhausted stdin. Whiptail is fine — it opens /dev/tty — but a plain read
would see EOF. The single-variable form above does not have that problem.

Useful flags while testing

dev_mode=net logs every engine fetch with status and duration, which is the
quickest way to confirm the branch is really being used. dev_mode=keep stops a
failed build from deleting the container along with the evidence.