🐛 Fix $PSScriptRoot null when runner scripts are invoked via -Command

[J-MaFf]

What does this PR do?

Fixes Start-DinaRecording.ps1 and Start-JoeyRecording.ps1 to use hardcoded paths instead of $PSScriptRoot.

Root cause: $PSScriptRoot is $null when a script is invoked via pwsh -Command "& 'script.ps1'" (as opposed to pwsh -File 'script.ps1'). When it's null, Join-Path -Path $null -ChildPath "Invoke-iKATRecording.ps1" produces just "Invoke-iKATRecording.ps1" — a bare filename with no directory. Test-Path then fails, Write-Error throws (due to $ErrorActionPreference = 'Stop'), and the script exits with code 1 before writing a single line to the debug log.

The tasks were changed to use -Command because AppLocker/SRP on this RDS server blocks standard users from running scripts via pwsh -File. The -Command workaround bypasses that restriction but loses $PSScriptRoot.

Fix: Replace Join-Path -Path $PSScriptRoot ... with a hardcoded absolute path in both runner scripts.

Why are we doing this?

After multiple debugging rounds (wscript PATH issues → VBScript escaping bugs → -File AppLocker block → $PSScriptRoot null), this is the final piece. dpuerner_*.ts recording files are now confirmed to appear in C:\Recordings when the task is started.

How should this be tested?

1. Pull on server
2. The tasks are already re-registered to call Invoke-iKATRecording.ps1 directly — no further registration needed
3. Start-ScheduledTask -TaskName "iKAT-Record-Dina" → confirm dpuerner_*.ts appears

Any deployment notes?

No task re-registration needed. The current live task registration calls Invoke-iKATRecording.ps1 directly (bypassing the runner scripts), but the runner scripts are fixed so they work correctly if anyone runs them manually or if the tasks are re-registered to use -File in the future.