start/sniff-start: refuse to run in Windows-hosted shells

A Windows user could run the bash launchers from WSL or Git Bash / MSYS2 /
MinGW / Cygwin, where the Linux USB assumptions do not hold: WSL cannot reach
the Windows SIMtrace2 device, and those shells have no Linux /sys + /dev/bus/usb
view for the udev pre-flight.  Both launchers now detect a Windows host up
front (WSL via /proc/version, the rest via uname -s) and exit 2 with a pointer
at the matching .bat launcher, which drives the Windows Python/PyUSB stack.
The message goes to stderr; a deliberate WSL/Cygwin flow can still run the
Python module directly (noted in the source comment).

Tests: tests/test_launchers.py runs each script with a fake mingw uname and
asserts exit 2 plus the start.bat/sniff-start.bat pointer, pins the WSL
detection, and checks bash -n syntax (skipped when bash is absent).

Bumps 2.7.14 (version.py, pyproject, PWA_VERSION), SW cache v96, the README
download examples and the release-notes preamble.  561 Python + 80 Node tests.

sniff-start.sh

@@ -8,6 +8,20 @@
 set -euo pipefail
 shopt -s nullglob
 
+# Windows guard: sniff-start.sh is the native Linux/macOS launcher.  Under WSL
+# the Linux guest cannot reach the Windows SIMtrace2 USB device, and a Git Bash /
+# MSYS2 / MinGW / Cygwin shell has no Linux /sys + /dev/bus/usb view for the
+# permission pre-flight below.  Use sniff-start.bat from cmd.exe or PowerShell,
+# which drives the Windows Python/PyUSB stack.  A deliberate WSL/Cygwin flow can
+# run `python -m simtrace2_pysniff` directly.
+if grep -qi microsoft /proc/version 2>/dev/null || \
+   uname -s 2>/dev/null | grep -qiE 'MINGW|MSYS|CYGWIN'; then
+    echo "Error: sniff-start.sh is the Linux/macOS helper and cannot run on Windows" >&2
+    echo "(WSL / MSYS2 / MinGW / Cygwin detected)." >&2
+    echo "Use sniff-start.bat from a Windows command prompt (cmd.exe / PowerShell) instead." >&2
+    exit 2
+fi
+
 PROJECT_DIR="$(cd "$(dirname "$0")" && pwd)"
 
 GSMTAP="${GSMTAP:-}"