[Bug]: dtvem init auto-elevation on Windows reports success but fix doesn't take

[CalvinAllen]

Reported by @BradKnowles in #247 (comment).

Description

When running dtvem init from a non-administrator terminal on Windows, the user is prompted to elevate. Accepting the UAC prompt does not appear to apply the PATH fix in the original session. Opening a new terminal as Administrator and running dtvem init from there works as expected.

Steps to Reproduce

1. Open a non-administrator terminal (PowerShell or cmd) as a user with admin rights
2. Run dtvem init
3. When prompted to re-run with administrator privileges, accept the UAC elevation prompt
4. Return to the original (non-admin) terminal and verify whether the PATH change took effect

Expected Behavior

After accepting the UAC prompt, dtvem init should reliably apply the System PATH change such that re-opening any terminal (admin or not) reflects the fix, and the original terminal should not falsely report success if the work was delegated to a child process whose result is unknown.

Actual Behavior

The fix does not appear to take effect in the original session. Running dtvem init from a separately-launched Administrator terminal succeeds.

Operating System

Windows

dtvem Version

0.5.5

Go Version (if building from source)

No response

Which runtime is affected?

Not runtime-specific

Error Messages / Logs

No error messages are displayed

Configuration

Additional Context

Likely root cause in src/internal/path/path_windows.go relaunchElevated (around line 237):

• The elevated child is launched via ShellExecute with the runas verb. This is fire-and-forget — the parent (non-admin) process does not wait for the child to finish or check its exit code.
• After spawning the child, the parent returns nil from AddToPath, and cmd/init.go proceeds to write the settings file and prints dtvem initialized successfully! plus the "Next steps" message — even though the actual PATH modification has been delegated.
• The elevated child opens in a separate console window. Once it finishes, the window closes immediately, so the user has no opportunity to see what happened.
• The relaunch hardcodes args := "init" and does not forward the original flags (--yes, --user, DTVEM_VERBOSE, etc.).

Suggested direction:

• Use ShellExecuteEx with SEE_MASK_NOCLOSEPROCESS, then WaitForSingleObject on the returned process handle and read GetExitCodeProcess so the parent can propagate the child's result.
• Only emit the success message in the parent if the child actually completed successfully (or restructure so the parent doesn't claim success at all when delegating to a child).
• Forward original CLI flags / env to the elevated child instead of hardcoding init.
• Consider keeping the elevated console window open long enough for the user to see the result, or print a clear summary in the parent after the child exits.

Code of Conduct

• I agree to follow this project's Code of Conduct