fix(argo): give container QA targets uinput access and setuptools

[castrojo]

Two nested-target environment gaps that only became visible once the headless
GNOME Shell drop-in (#614/#615) let container QA lanes execute scenarios at all.

/dev/uinput — 7 scenario failures

dogtail/qecore synthesise key combos through /dev/uinput and were aborting with:

RuntimeError: User 'bluefin-test' does not have write permissions for '/dev/uinput'.

Verified live inside lane testsuite-738-…-zqkdc (the lane that produced the
triage evidence):

$ podman exec bluefin-qa-target id bluefin-test
uid=1000(bluefin-test) … groups=…,39(video),105(render),104(input)
$ podman exec bluefin-qa-target ls -l /dev/uinput
crw-------. 1 root root 10, 223 /dev/uinput

/etc/group is not corrupt — video, render and input all resolve and all
list bluefin-test. The node simply has mode 0600 root:root and no group, so
group membership can never grant access.

/dev is also not shared with the node — podman gives the target its own tmpfs:

outer pod:  5243088 334
nested tgt: 2097210 269   # different device and inode

Because the node is lane-local, chgrp input /dev/uinput && chmod 0660 /dev/uinput
is both sufficient and safe: it cannot affect a concurrent lane or ghost itself.

pkg_resources — 124 log occurrences

Traced to a single call site:

qecore/sandbox.py:3353  in _attach_version_status_to_report
    import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

pkg_resources ships only with setuptools, was removed in setuptools 81, and is no
longer seeded into fresh Python 3.12+ environments.

Honest scoping: that method is decorated @non_critical_execution
(qecore/utility.py:37), which catches the exception and embeds it. So these 124
occurrences are lost version reporting and log noise, not scenario failures —
fixing it will not by itself move the pass tally. It is still worth fixing: it
restores the HTML report's version table and stops burying real errors under ~600
lines of traceback.

Environment snapshot

Container lanes are only observable through Argo logs. Every fact needed to triage
this batch (shell cmdline, uinput mode, app presence) required exec'ing into a live
lane. A bounded, non-fatal snapshot now runs before behave.

Explicitly not changed

• No --unsafe-mode regression. Verified on a live lane:
  /usr/bin/gnome-shell --mode=user --unsafe-mode --headless --virtual-monitor 1920x1080
  and gdbus … org.gnome.Shell.Eval "global.context.unsafe_mode.toString()" →
  (true, '"true"'). The Shell.Eval … failed (rc=1) errors are transient gdbus
  failures in testsuite step helpers, not a drop-in defect.
• Headless does not imply llvmpipe. The lane's shell logs
  Created gbm renderer for '/dev/dri/renderD128' — a real render node. The
  No software rendering fallback (LLVMpipe) scenario stays semantically valid.
• SSH failures are a testsuite concern → test(smoke): skip @vm_only scenarios in container lanes testsuite#740 (@vm_only).
• Settings not found via AT-SPI is not an infrastructure gap:
  gnome-control-center-50.3-1.fc44 is installed and launches under the session
  environment. Left for separate testsuite-side investigation rather than guessed at.

Validation

• just lint ✅
• YAML parses; bash -n clean on both the outer script and the extracted NESTED_SETUP body ✅
• kubectl apply --dry-run=server ✅
• python3 -m pytest tests/unit/ -q — only the 6 pre-existing failures on clean main
  (test_bst_poller_admission, 3× test_recc_runner_seam, test_zot_cache_policy,
  test_page_dataset_collector; the last confirmed pre-existing by stashing this diff)

The NESTED_SETUP quoted heredoc is untouched; no bash -c '…' was introduced.

Assisted-by: Claude Opus 5 via GitHub Copilot CLI