[BUILD] Packaging follow-ups: Ubuntu 22.04 compat, rpath audit, per-branch backends, vendor runtime deps

Follow-up to #794/#796. Four concerns were raised about the deb/rpm packaging; each was verified against main and the built artifacts. Status and actions below. (I'll take this — please assign to @shiptux.)

### 1. Wheels built on Ubuntu 24.04 are unusable on 22.04 — confirmed
`libtriton.so` requires `GLIBC_2.38` / `GLIBCXX_3.4.32` (verified with `strings`); Ubuntu 22.04 ships glibc 2.35 / GLIBCXX 3.4.30. The deb's `${shlibs:Depends}` does work — the built package declares `libc6 (>= 2.38), libstdc++6 (>= 13.1)`, so 22.04 fails at install time, not at runtime.
- [x] Add an `ubuntu:22.04` matrix variant (#1066) (`DEB_BASE_IMAGE` is already parameterized; the same-base two-stage build handles the py3.10 ABI automatically)
- [ ] Longer term: evaluate a manylinux-style wheel to cover multiple distros with one build

### 2. rpath / hardcoded paths — not reproduced on main (nvidia)
All shipped `.so` files have **no RPATH/RUNPATH**, `DT_NEEDED` lists only system libs, and `patchelf` has zero occurrences on main (repo grep + GitHub code search). The reported `patch_elf` hardcoding lives on vendor-backend branches, so this becomes relevant when packaging those backends.
- [x] Re-verify on a current 0.6.0 wheel (adds libproton.so and instrumentation libs) — done 2026-08-30, see comment: no RPATH/RUNPATH, system-only DT_NEEDED
- [x] Add an `import triton` smoke test to the assembler stages (in Dockerfile.deb since #794; both #1066 rows run it) — CI is currently blind to the whole "installs fine, fails at import" class (covers both #1 and #2)
- [ ] When packaging a vendor backend: audit its `.so` files for RPATH/hardcoded paths; patch to `$ORIGIN`-relative where needed

### 3. Backends live on separate branches — confirmed
Upstream has many per-backend branches (`ascend_*`, `backend/enflame/*`, `feat/mthreads-*`, ...). Packaging files exist only on main, so "add a matrix entry" is not enough for other backends.
- [ ] Per-backend packaging should be driven by backend-variant tags (`0.6.0+mthreads3.6`) — a tag push checks out the tagged branch; the current job-level `+` skip in the workflows is the placeholder to replace with a tag→backend mapping
- [ ] Packaging files need to be synced/cherry-picked to backend branches (or wait for branch consolidation)

### 4. Vendor runtime deps are huge and undeclared — confirmed for tsingmicro
`python/setup_tools/setup_helper.py` (tsingmicro section) pulls a full LLVM toolchain tarball plus `tx8_deps` and requires `TX8_DEPS_ROOT` at build time; nothing distinguishes build-time from runtime deps. Distro packages can't declare these as `Requires`/`Depends` (not in any repo), and bundling them explodes package size and CI disk.
- [ ] Decide a per-backend packageability policy: self-contained backends (nvidia/amd) get standard packages; vendor-dep backends get `Recommends` + documented manual install, or require a vendor apt/yum repo
- [ ] Note: the tsingmicro toolchain targets glibc 2.30 / GLIBCXX 3.4.28 (per its tarball name) — conflicts with a 24.04 build base; interacts with #1

Start with Dockerfile.deb and the workflow matrix, including the existing Ubuntu 22.04 variant and import smoke test. Then read the tsingmicro section in python/setup_tools/setup_helper.py and inspect the current backend-branch packaging assumptions. Done means the unresolved backend mapping, vendor dependency policy, and artifact compatibility requirements have explicit, tested packaging outcomes.

Written by the indexing model from the issue text.