🐛 Fix VBS launchers using bare pwsh.exe — recording never starts for dpuerner

[J-MaFf]

What does this PR do?

Fixes a bug where the iKAT recording task starts successfully (exit code 0) but never produces a recording file or any log output for dpuerner.

Root cause: Both VBS launcher files called pwsh.exe by name only. When wscript.exe launches a process via WScript.Shell.Run, it resolves executables against the system PATH for that user's session. pwsh.exe is installed at C:\Program Files\PowerShell\7\pwsh.exe and while this is in the PATH for admin sessions, it was not resolving correctly when launched via wscript in dpuerner's RDS session — causing wscript to silently return 0 without ever starting PowerShell.

Fix: Replace pwsh.exe with the full absolute path "C:\Program Files\PowerShell\7\pwsh.exe" in both .vbs launchers.

Files changed:

• Scripts/iKAT/Invoke-FFmpegCapture/Start-DinaRecording.vbs
• Scripts/iKAT/Invoke-FFmpegCapture/Start-JoeyRecording.vbs

Why are we doing this?

Discovered when manually testing by running Start-ScheduledTask -TaskName "iKAT-Record-Dina" while dpuerner was active — task reported success but no .ts file or debug.log entry was produced. A diagnostic task using the full pwsh path confirmed dpuerner's session and USERNAME were correct; the only issue was wscript failing to locate pwsh.exe by name.

How should this be tested?

1. Pull on server: git pull
2. Manually run: Start-ScheduledTask -TaskName "iKAT-Record-Dina" (while dpuerner is logged on)
3. Wait ~5 seconds — confirm a dpuerner_*.ts file appears in C:\Recordings and is growing
4. Check C:\Recordings\debug.log for a Script started. USERNAME=dpuerner entry

Any deployment notes?

Pull on server — no task re-registration required since the tasks call the .vbs files by path, and the .vbs content is what changed.

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