fix: tools/bugreport launcher finds a Python 3.8+ itself and never starts a Store alias (#166)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2

Files changed:
- .gitea/workflows/ci.yml
- CHANGES.md
- INSTALL.md
- VERSION
- instructions/bug-report.md
- tools/README.md
- tools/bugreport
- tools/bugreport.ps1
- tools/bugreport.py
- tools/chemenu/tests/test_bugreport_launcher.py
- tools/chemenu/tests/test_instructions_shell.py
- tools/chemenu/tests/test_portability.py

CHANGES.md

@@ -59,7 +59,7 @@ concern - readable here, never shipped as something to parse.
 
 ---
 
-## 8.0.0-beta.21 - 2026-10-02 - INSTALL.md an die Installationsinstruktionen gekoppelt: Voraussetzungen generiert, Setup-Fragen geprüft
+## 8.0.0-beta.22 - 2026-10-02 - tools/bugreport: Starter für den Bugreport-Sammler, überspringt die Store-Aliase (#166)
 
 **Author:** Torben Nehmer
 
@@ -96,6 +96,7 @@ concern - readable here, never shipped as something to parse.
 - trace-hook.ps1: Copilot hooks no longer open Windows' choose-an-app dialog
 - Windows-Portabilität: Pfadtrenner, Zeilenenden, Encoding und Locks
 - INSTALL.md an die Installationsinstruktionen gekoppelt: Voraussetzungen generiert, Setup-Fragen geprüft
+- tools/bugreport: Starter für den Bugreport-Sammler, überspringt die Store-Aliase (#166)
 
 **Low impact**
 - version bump no longer points at version release in its output
@@ -133,6 +134,30 @@ concern - readable here, never shipped as something to parse.
 - preflight.ps1: the asset-mode error helper is Exit-Asset, so PSScriptAnalyzer passes
 <!-- /wikitool:bumps -->
 
+### `tools/bugreport`: the collector finds its own Python (#166)
+
+The bug-report collector is the one part of the stack that has to run when nothing else does,
+and it was started as `python3 tools/bugreport.py`. On the Windows target that name is the
+Microsoft Store's alias in Git Bash, and in PowerShell `python` can be one too - so the report
+failed exactly where it was needed.
+
+It now has a launcher pair after the pattern of `tools/wikitool`: `tools/bugreport` (sh, for
+Linux, macOS and Git Bash) and `tools/bugreport.ps1`, which PowerShell resolves the same string
+to first. They look for a Python the way the preflight does - `python3`, `python` on `PATH`; on
+Windows `python`, `py -3`, `python3`, with the registry's `PATH` added under PowerShell - and then
+try the venv's. Each candidate is probed for 3.8 or newer before it runs anything, and nothing
+under `WindowsApps` is ever started. One that is too old, or that the machine refuses (a venv
+`python.exe` blocked by Defender), is passed over. Finding none, the launcher exits 1 and says
+why, naming any Python it found too old and the direct call with a full path as the way out.
+Neither launcher assumes the preflight, `.wikitool-tools.json` or the venv, and the PowerShell
+one keeps to what Windows PowerShell 5.1 understands, so a report never fails on the shell's
+version first.
+
+`instructions/bug-report.md`, `INSTALL.md` § Troubleshooting, the stage-2 line the collector
+prints and the CI step that runs it in the distribution all use `tools/bugreport`. The shell test
+for shipped instructions now refuses a bare `python3`/`python`/`py` call in a command block.
+Starting `bugreport.py` directly still works.
+
 ### INSTALL.md held to the installation instructions (#154)
 
 The installation procedure has one source, the instructions under `instructions/`; `INSTALL.md`