fix(webview): stop Pi 2/3 blank screen from gcc NEON alignment SIGBUS - #3184

The Qt5 WebEngine viewer crash-loops on the Pi 2 (and any armv7/Cortex-A
board), leaving a permanent blank screen: AnthiasViewer SIGBUSes on an
unaligned 64-bit NEON store (vst1 {q8},[rN:64]) that modern Debian gcc
(12-16) emits for struct zero-init/copy of 8-byte-aligned types via its
arm_block_set_aligned_vect block-move expander. Chromium/Qt hand some of
those pointers 4-byte-aligned addresses, so the :64 alignment assertion
faults on the Cortex-A7; the kernel can't fix up NEON, so it SIGBUSes.
gcc treats this as correct codegen (GCC PR 93031, WONTFIX); the previously
shipped toolchain only escaped it because it predated the Linaro->Debian
gcc switch.

Fix (both required):
- Append arm_use_neon=false to QtWebEngine's Chromium gn args (the fix
  Yocto's meta-chromium / meta-lgsvl-browser ship) so general C++ compiles
  -mfpu=vfpv3-d16; codec/graphics (libvpx, Skia) re-add NEON per-file with
  runtime detection, preserving HW SIMD decode.
- Wrap the armhf cross gcc/g++ with -mno-unaligned-access so BOTH the
  qmake-built Qt libs and Chromium's gn build lower the block move to
  4-byte-safe vstr. arm_use_neon=false alone doesn't cover Qt's own libs.

Also makes the Qt5 toolchain rebuildable on Debian trixie (Python 3.13),
which dropped stdlib modules Chromium 87's build tooling still imports:
imp/pipes/cgi shims (src/anthias_webview/pyshim/) installed into python3
site-packages, a distro-six overwrite for grit's vendored six, and
python3-six/setuptools installs.

Validated on a real Pi 2: 0 alignment traps, stable viewer, renders
image/video/webpage, on the latest Qt 5.15.19 + Debian gcc-14.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

The imp/pipes/cgi shims run only inside the Qt 5 toolchain builder image
to satisfy Chromium 87's Python-2-era build tooling on trixie's Python
3.13; they emulate removed-stdlib APIs, so the app's strict typing and
formatting rules don't apply. Same treatment as the sibling
sysroot-relativelinks.py already gets.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

- pyshim copy: guard on the glob matching real files so an empty/absent
  dir doesn't hand cp a literal `*.py` and abort under set -e.
- -mno-unaligned-access wrapper: only wrap when the tool exists and isn't
  already wrapped (idempotent; doesn't pre-empt fetch_cross_compile_tool's
  own presence check).
- arm_use_neon=false: grep-guard the common.pri append so a rebuild in the
  same workdir can't duplicate the line.
- Bump the remaining WebView-v2026.07.0 references (docs, scripts, github
  release-filter test fixtures) to 07.1 for consistency with the pinned
  toolchain release.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

The Qt5 builder image installs python3 but not python3-pip, so the
`|| pip3 install ...` fallback for six/setuptools could never actually
run — if the apt install fails the pip3 call just errors with
command-not-found. Install via apt only and let a real failure abort the
build (set -e), which is the honest behaviour.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

find_module() computed a file handle from spec.origin unconditionally; for
built-in/frozen modules origin is the sentinel 'built-in'/'frozen' (and
None for namespace packages), so open() would fail. Only open a genuine
file-backed origin.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

The vendored-six overwrite swallowed all errors (2>/dev/null || true).
six is installed earlier in the script so the import can't fail, and a
silently-failed overwrite would only resurface later as the exact
"No module named 'six.moves'" grit crash this step exists to prevent.
Drop the swallowing and fold the two finds into one.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

… handling

Address Copilot review round 7 on the Python 3.13 `imp` shim:

- find_module() now resolves built-in and frozen modules the way the
  historical stdlib imp did when called with no explicit path: check
  sys.builtin_module_names / FrozenImporter first (no import side
  effects) and return C_BUILTIN / PY_FROZEN with a None pathname
  instead of leaking importlib's 'built-in'/'frozen' sentinel through
  as a fake filename. PathFinder alone never surfaced these (they're on
  no path), so it previously raised ImportError for e.g. `sys`.
- load_module() no longer assumes every PKG_DIRECTORY has an
  __init__.py: namespace packages (which find_module also classifies as
  PKG_DIRECTORY) now fall through to importlib.import_module instead of
  exec'ing a non-existent <dir>/__init__.py and raising.

Verified against built-in (sys), frozen (_frozen_importlib), regular
package (json), source module, and a synthetic namespace package.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

…-neon-alignment-blank

# Conflicts:
#	tools/image_builder/utils.py