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

tools/README.md

@@ -76,6 +76,9 @@ tools/
   prerequisites.txt        what the machine needs, one `|`-separated line per tool - read by the preflight and `doctor`
   trace-hook               what the harness hooks call: trace_ingest.py under the venv's Python
   trace-hook.ps1           the same for PowerShell, which resolves `./tools/trace-hook` to this file first - without it Windows asks which app opens the sh script
+  bugreport                entry point for the bug-report collector (POSIX sh): finds a Python 3.8+ on PATH itself, skipping the Microsoft Store aliases, and runs bugreport.py - no preflight needed
+  bugreport.ps1            the same for PowerShell, which resolves `tools/bugreport` to this file first; keeps to what Windows PowerShell 5.1 understands
+  bugreport.py             the bug-report collector itself - see below
   chemenu/
     cli.py                 Typer app: registers every command, runs the budget gate, renders `-h`/`--help` from cli_contract
     cli_contract.py         one data record per command (name, synopsis, properties, exit status) - the source `-h`, the index and CONTRACT.md's generated region render from
@@ -119,6 +122,13 @@ survive. The mapping, the review list and the candidate file stay beside the bun
 `dist export` ships it with the rest of `tools/`;
 its tests (`tests/test_bugreport.py`) run it on a bare interpreter (`-I -S`) to keep that promise.
 
+It is started through `tools/bugreport` (`bugreport.ps1` under PowerShell), which assumes no more
+than the collector does: no preflight, no `.wikitool-tools.json`, no venv. It looks for the
+interpreter the way the preflight does - `python3`, `python` on `PATH`; on Windows `python`,
+`py -3`, `python3` - then tries the venv's, probes each for 3.8 or newer, and never starts one under
+`WindowsApps`, where `python3` in Git Bash is the Microsoft Store's alias. Finding none, it exits 1
+and says why.
+
 **Two consumers, one core.** The CLI is not the only caller any more. The cores
 (`search/service.py`, `lint_core.py`, `types_core.py`, `catalog.py`) hold what
 decides an answer and import no `typer` and no `rich`; the modules under `commands/` turn