Fix taking-fire ally misclassification; Windows build fixes; Field Gun

OCR (src/fenigma/ocr.py):
- A "taking fire" report's reporting unit was added as a hostile Target,
  not a friendly Ally -- no "Friendly"/"Hostile" prefix word exists in
  that grammar for the usual inference to key off of, so it silently
  defaulted to not-ally. Fixed with an explicit force_ally override
  (_TAKING_FIRE_RE), and the shell/deadline (which an Ally tuple has no
  fields for) now always splits into a synthetic StrikeRequest target at
  the reporting position, even for the no-offset "on our position" case
  that previously kept them on the entity itself.
- "Enemy <Type>#<id> Destroyed" kill-feed lines were silently dropping
  for shorter/less distinctive type words (e.g. "Enemy Field Gun#1") --
  _ALLY_PREFIX_RE only ever stripped "Friendly"/"Hostile", never
  "Enemy", so the whole "EnemyFieldGun" token got alias/fuzzy-matched
  against "Artillery" and missed by a mile. Longer type words
  ("Enemy Mechanized Infantry#2") only ever worked by fuzzy-match
  accident. Now strips "Enemy" too (lookahead guards a BARE "Enemy#N"
  report, which IS TargetType.ENEMY itself, from being stripped to an
  empty, unresolvable string).
- "Field Gun" added to _TYPE_WORD_ALIASES as plain Artillery under
  another name (confirmed by the user), not a missing unit type.
7 new/updated regression tests, 54 total passing.

Windows build (packaging/windows/): three real bugs found and fixed by
actually booting and driving the build VM live (VNC), not just guessing
from the README's "UNTESTED end to end" note:
- install.bat's MSYS2/WiX provisioning previously left NOTHING behind
  once C:\OEM stopped existing (a 2-day-old BUILD_REQUEST sat unclaimed
  the whole time) -- the build.bat/watch_build.bat persistence fix
  (C:\FenigmaBuild instead of C:\OEM) is real and now confirmed live:
  after a full container restart, the watcher auto-starts on login and
  picks up a pending request with zero manual intervention.
- pip install pytesseract needs --break-system-packages (MSYS2's
  mingw64 Python enforces PEP 668).
- mingw-w64-x86_64-opencv is the C++ library only; the actual Python
  bindings are the separate mingw-w64-x86_64-python-opencv package,
  never in install.bat's dependency list.

With all three, import fenigma.app succeeds and a real build attempt
gets through source copy, sanity check, dist-tree assembly, and WiX
harvest+compile -- further than this pipeline has ever gotten. Full
findings, including the still-open light.exe timeout and the OCR
multi-shell/deadline-phrasing/phantom-header gaps found along the way,
logged in TODO.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

packaging/windows/oem/watch_build.bat

@@ -1,5 +1,8 @@
 @echo off
-REM Runs persistently from system boot (see install.bat's scheduled task).
+REM Runs persistently from login (see install.bat's Startup-folder entry --
+REM this file itself gets copied to C:\FenigmaBuild\ and to the Startup
+REM folder by install.bat, not run from C:\OEM, which does not reliably
+REM survive past Windows Setup finishing, see install.bat's own note).
 REM Polls the host-shared Z:\ drive for a build request and, when one
 REM shows up, runs build.bat against it. This is what lets build_windows.sh
 REM on the Linux host trigger a build without any RDP/remote-exec: it's
@@ -17,14 +20,14 @@ if not exist Z:\ (
 if exist Z:\BUILD_REQUEST (
   REM Claim the request before acting on it -- if watch_build.bat somehow
   REM ended up running twice this boot (install.bat starts it once
-  REM immediately, the ONSTART task could also fire the same boot), only
+  REM immediately, a fresh login could also start another copy), only
   REM one of them wins this move and actually builds.
   move /y Z:\BUILD_REQUEST Z:\BUILD_REQUEST.claimed >nul 2>&1
   if exist Z:\BUILD_REQUEST.claimed (
     del Z:\BUILD_REQUEST.claimed
     del /q Z:\BUILD_DONE 2>nul
     del /q Z:\BUILD_FAILED 2>nul
-    call C:\OEM\build.bat
+    call C:\FenigmaBuild\build.bat
   )
 )
 timeout /t 5 /nobreak >nul