fix(pve): use pveam for Debian ARM64 templates

[I-am-PUID-0]

✍️ Description

While validating the new DUMB (Distributed Unlimited Media Bridge) LXC script on a native ARM64 Proxmox VE host, container creation failed before the application installer was reached.

The split Core engine currently treats every ARM64 PVE container as requiring a custom template. For Debian, that path queries the community-scripts/debian-arm64-lxc latest-release API endpoint, which returns 404 Not Found, and pipes the response through jq before Core has ensured that jq is available. Consequently, any new ProxmoxVED script requesting a Debian container on ARM64 can fail during template acquisition; the problem is not specific to DUMB.

The existing production ProxmoxVE/ct/debian.sh script can still work because it uses the legacy monolithic misc/build.func implementation rather than this split Core template path. Its success therefore does not validate the path used by new ProxmoxVED scripts.

Proxmox VE 9.2 now exposes official Debian ARM64 standard templates through pveam. A live ARM64 catalog contained both AMD64 and ARM64 Debian entries, so routing Debian through pveam also requires exact architecture filtering throughout template discovery. Without that filtering, local, online, fallback, or interactive selection could choose a template for the wrong architecture and fail later during container creation.

This change:

• Routes Debian ARM64 through the official Proxmox pveam catalog.
• Filters local, online, fallback, previous-version, and interactive template selections by the host's exact architecture.
• Removes the dependency on the nonexistent community-scripts/debian-arm64-lxc release source.
• Preserves the existing Jenkins custom-template path for Ubuntu, Alpine, and other ARM64 distributions.
• Keeps non-PVE ARM64 version resolution unchanged.
• Adds an ARM64 template-routing regression test to the split-file verification workflow.

AI assistance: OpenAI Codex (GPT-5.6-Sol, high reasoning) assisted with implementation and testing. I reviewed the resulting changes and take responsibility for them.

Testing

Automated validation:

• bash tests/arm64-template-routing.sh
• Bash syntax validation for all Core .func files
• Blocking ShellCheck validation
• shfmt validation of the changed code
• Prefetch-list verification
• Loader/API snapshot verification
• git diff --check

Live Proxmox VE validation:

• AMD64 Debian 13 selected the exact AMD64 pveam template.
• ARM64 Debian 13 selected and downloaded debian-13-standard_13.6-1_arm64.tar.zst from an initially empty template cache.
• The ARM64 Debian container was created unprivileged, booted, and received working networking.
• ARM64 Ubuntu 24.04 retained and completed the Jenkins noble custom-template path.
• A clean ARM64 installation using the downstream DUMB (Distributed Unlimited Media Bridge) LXC script completed successfully. It installed DUMB 2.21.0 natively in an unprivileged Debian 13 container, and both the DUMB API and web frontend became healthy.

✅ Prerequisites (X in brackets)

• Self-review completed – Code follows project standards.
• Tested thoroughly – Validated on AMD64 and ARM64 Proxmox VE hosts.
• No security risks – No secrets, privilege changes, or permission changes are introduced.
• API.txt regenerated – Not applicable; no loader API snapshot changed, and the existing API snapshot checks pass.

---

🤖 AI Assistance (X in brackets)

If you used an AI tool (GitHub Copilot, Claude, ChatGPT, etc.) to write or generate any code in this PR, you must confirm compliance below.
Select exactly one option.

• No AI used – Code was written without AI assistance.
• AI was used – The output has been reviewed and corrected, and I take responsibility for it matching this repo's conventions.

---

🛠️ Type of Change (X in brackets)

• 🐞 Bug fix – Resolves an issue without breaking functionality.
• ✨ New feature – Adds new, non-breaking functionality.
• 💥 Breaking change – Alters existing behavior in a way that may require updates in every downstream script.
• 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
• 📝 Documentation update – Changes to README, docs/, CONTRIBUTING.md, or other docs.

[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/I-am-PUID-0/core/fix/debian-arm64-pveam-template \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVED/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/I-am-PUID-0/core/fix/debian-arm64-pveam-template/tools/run.sh |
  bash -s -- https://raw.githubusercontent.com/YOU/ProxmoxVED/your-branch ct/debian.sh \
             https://raw.githubusercontent.com/I-am-PUID-0/core/fix/debian-arm64-pveam-template

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.