🐛 Fix recording stopping when user triggers UAC elevation

[J-MaFf]

What does this PR do?

Fixes a bug where the iKAT session recording would permanently stop whenever the recorded user (dpuerner) launched a process as administrator (triggering a UAC elevation prompt). Also adds logarithmic backoff to the restart loop so rapid UAC transitions recover in ~1 second while genuinely broken FFmpeg processes back off gradually.

Changes:

• Invoke-iKATRecording.ps1 — Wraps the FFmpeg launch in a restart loop. When FFmpeg exits mid-session (e.g., due to a UAC secure desktop transition), the script detects the session is still active via an explorer.exe presence check and starts a new recording segment automatically. Each segment shares a session timestamp and gets an incrementing part number (_part1.ts, _part2.ts, …).
• UAC exit-code fix: gdigrab exits with code 0 (clean) — not a crash code — when the UAC secure desktop dismisses its handle. The original non-zero exit-code check incorrectly treated UAC exits as graceful logoffs. Fixed by checking for explorer.exe instead: if Explorer is still running, the session is active and FFmpeg is restarted regardless of exit code.
• Logarithmic backoff: Restarts 1–10 wait 1 second (fast recovery for back-to-back UAC prompts); restarts 11+ use Round(Ln(restartCount - 9) * 5) seconds (~3s at restart 11, ~20s at restart 60). Max restart count raised from 5 → 60, rolling window from 10 → 60 minutes.
• Tests/iKAT/ — Renamed test folder from iCat → iKAT to match the script directory casing.
• .github/copilot-instructions.md — Added iKAT recording project conventions section documenting critical constraints (MPEG-TS format, zerolatency, flush_packets, RunLevel Limited, restart loop, explorer.exe session detection) so future changes don't accidentally revert hard-won fixes.

Why are we doing this?

When Windows shows a UAC elevation prompt, it switches from the user's normal desktop (Winsta0\Default) to an isolated secure desktop (Winsta0\Winlogon). The gdigrab -i desktop handle becomes invalid during this switch, causing FFmpeg to exit with code 0 (a clean exit — not a crash). Without the restart loop the recording ended at that point, potentially losing all footage of whatever happens after the elevation prompt — exactly what we're trying to diagnose.

The logarithmic backoff ensures UAC-triggered restarts (which happen multiple times per session) resume recording with no noticeable gap, while a genuinely crashing FFmpeg process doesn't hammer the CPU in a tight loop.

Closes #88

How should this be tested?

1. Log on to KFWS6IKAT01.kikkoman.com as KFI\admin-jmaffiola
2. Confirm a _part1.ts file appears in C:\Recordings and is growing
3. Right-click any application → Run as administrator → trigger the UAC prompt (accept or deny, doesn't matter)
4. Within ~1 second, confirm a _part2.ts file appears in C:\Recordings and starts growing
5. Log off → confirm the last .ts file is fully playable in VLC with no truncation
6. Check C:\Recordings\debug.log for "FFmpeg exited with code", "Explorer still running", and "Launching ffmpeg" entries showing the restart

Pester tests: All 6 tests pass:

Tests Passed: 6, Failed: 0, Skipped: 0

Any deployment notes?

Pull the fix on the server:

Invoke-Command -Session $s {
    Set-Location C:\PowerShellScripts
    git pull
}

No Task Scheduler changes required — the tasks (iKAT-Record-Dina, iKAT-Record-Joey-Test) do not need to be re-registered. All fixes are within the PowerShell script itself.

Closes #88