Setup-OpenText: Resolve-Path on SourceDir to flatten the CMD shim's "..\..\apps\opentext"

The shim Setup-OpenText.cmd hands "%~dp0..\apps\opentext" to the PS1.
PowerShell's Join-Path leaves the literal ".." segment in the path it
passes to msiexec, and the Windows Installer service rejects the package
with 1619 (ERROR_INSTALL_PACKAGE_OPEN_FAILED) for that reason. Every
other API resolved the path fine, masking the issue. Resolving SourceDir
once at script entry collapses ".." so the downstream msiexec /i and /p
calls receive a clean drive-rooted path.

Verified end-to-end on the win11 VM via the GE-Enforce dispatcher: msiexec
/i and /p both return 3010 (treated as success), profiles + shortcuts +
marker land cleanly, total 36s.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

playbook/preinstall/opentext/Setup-OpenText.ps1

@@ -41,6 +41,16 @@ if (-not $SourceDir) {
     $SourceDir = $PSScriptRoot
 }
 
+# Normalize $SourceDir to a canonical absolute path. The CMD shim passes
+# "%~dp0..\apps\opentext" which embeds a literal "..". msiexec / the Windows
+# Installer service fail to open the package with that unresolved segment
+# (exit 1619, ERROR_INSTALL_PACKAGE_OPEN_FAILED), even though every other
+# .NET / PowerShell API resolves it fine. Resolve-Path collapses ".." into
+# a clean drive-rooted path before any msiexec invocation.
+if (Test-Path -LiteralPath $SourceDir) {
+    try { $SourceDir = (Resolve-Path -LiteralPath $SourceDir).ProviderPath } catch {}
+}
+
 # --- Inline site-config reader (this script runs from C:\PreInstall\installers\opentext\,
 # NOT from C:\Enrollment\shopfloor-setup\, so it can't dot-source Get-PCProfile.ps1) ---
 function Get-SiteConfig {