Configurable user-profile loading: WINRS_NOPROFILE is hardcoded (winrs -noprofile)

[bertysentry]

winrs parity: -nop[rofile] — except our polarity is reversed: winrs loads the profile by default and -noprofile turns it off; this client hardcodes WINRS_NOPROFILE=TRUE in the shell Create options, so the profile is never loaded and there is no way to ask for it.

Context

Envelopes.createShell always sends:

<wsman:Option Name="WINRS_NOPROFILE">TRUE</wsman:Option>

That is the safe default — winrs's load-the-profile default fails for users who are not local administrators on the target — but some commands genuinely need the user profile (HKCU hive, %APPDATA%, per-user PATH), and today they cannot have it.

Proposed API

CommandResult result = client.command("reg query HKCU\Software\...")
    .loadUserProfile()          // shell-scoped, like workingDirectory: first command pins it
    .execute();

Keep NOT loading the profile as the default — it is both the current behavior and the choice that works for non-admin users.

CLI

--profile on command (and shell, #136):

winrm-java -h server -u 'DOMAIN\user' -pf pw.txt --profile exec 'echo %APPDATA%'

Requirements

• Shell-scoped setting with the same pinning semantics as the working directory (replayed with its original value when a reaped shell is silently recreated).
• Document the failure mode: requesting the profile as a non-admin typically faults — the fault surfaces through the normal WinRMFaultException path with its code and detail.
• Tests: wire assertion of the option value on Create, pinned replay on recreation, CLI parsing; docs (commands.md + cli.md).

🤖 Generated with Claude Code