appimage.yml installs aqtinstall unpinned, so the tool that picks the AppImage's Qt is itself unreviewed

Start with .github/workflows/appimage.yml at lines 157-171, then compare the pinned aqtinstall setup in .github/docker/Dockerfile and the other workflows mentioned in the issue. Verify that both x86_64 and aarch64 AppImage builds use aqtinstall 3.3.0 in the runner-local virtual environment and still pass the existing Qt path checks.

Summary

appimage.yml installs the tool that chooses the Qt with no version constraint:

      - name: Install Qt 6.8.3 LTS via aqtinstall
        run: |
          pip3 install aqtinstall
          aqt install-qt ${{ matrix.qt_host }} desktop 6.8.3 ${{ matrix.qt_arch }} \

.github/workflows/appimage.yml L157-161.

Both AppImages — x86_64 and aarch64 — are built by this job, so this is on the
release path for two of the five shipped artifacts.

Why this is the same class of bug as #4688

#4688 was about what Qt each artifact links. This is about what decides that.
aqtinstall resolves the Qt version to a set of archive URLs, unpacks them, and
patches the .prl/CMake files it lays down. An unreviewed aqt upgrade is
therefore an unreviewed change to the Qt tree the AppImage links, arriving with
no PR and no review — the exact property #4688 §1 objected to in
brew install qt@6, one level up the stack.

It is not hypothetical that aqt's behaviour changes: aqt has changed its
install layout and its .prl patching between minor releases before, which is
why appimage.yml L165-171 derives QT_ROOT from the arch string rather than
hardcoding it, and why both it and macos-dmg.yml assert bin/qmake exists
afterwards. Those guards exist because the tool moves.

Current state after #4695

The Dockerfile already states the rationale:

aqtinstall is pinned. It is the tool that decides what Qt lands in this image,

appimage.yml is now the only place that doesn't follow it.

Suggested fix

Match the others, and take the venv with it — pip3 install into the runner's
system python is a PEP 668 hazard that only works today because the ubuntu
runner image happens to permit it:

    env:
      AQTINSTALL_VERSION: '3.3.0'
...
      - name: Install Qt 6.8.3 LTS via aqtinstall
        run: |
          python3 -m venv "$RUNNER_TEMP/aqtvenv"
          "$RUNNER_TEMP/aqtvenv/bin/pip" install -q "aqtinstall==${AQTINSTALL_VERSION}"
          "$RUNNER_TEMP/aqtvenv/bin/aqt" install-qt ${{ matrix.qt_host }} desktop 6.8.3 ${{ matrix.qt_arch }} \

Same value as the other three so a future Qt bump is one grep rather than four
independent decisions.

Scope

CI-only, no source change, and it cannot regress a build that currently passes —
pinning to the version CI already resolves to today is a no-op until aqt ships a
release that would have broken us.

Follow-up to #4695; belongs under #4688's umbrella but is not one of its numbered
sections.