fix(harness): the stored-password task is registered for the account's Windows name

[fadwen]

Summary

The stored-password task, the path -Credential takes when the account holds no session, was registered with the credential's user name as given. For a Microsoft Entra account's sign-in name the scheduler refuses that with "No mapping between account names and security IDs was done". The task is now registered for the name Windows gives the account, as the interactive task has been since #6.

Measured on the lab device while there: a stored-password task for an Entra account never starts on it, with or without the "Log on as a batch job" right, so the launcher's refusal for such an account now says that instead of pointing at the right.

Stacked on #10: this pull request's base is that branch, so its diff is its own change only. Merge #10 first; GitHub then retargets this one to main and its checks run.

What was measured

VM 125, the Entra test user signed out, Register-ScheduledTask -User <name> -Password <the account's password>:

Name	Registration	Run
user@domain	Refused: "No mapping between account names and security IDs was done"
AzureAD\user@domain	Registered	Sat Ready, 0x00041303 ("has not run yet"), LastRunTime unset
AzureAD\IslVerylongdisplayna	Registered	Same

With the account granted SeBatchLogonRight for the length of the test through secedit (taken away again afterwards), both registered names gave the same result. A local standard user without the right behaves the same way (Findings, "The harness as another account", 2026-09-29).

Changes

• Invoke-IslProcess. The stored-password task's -User is the resolved Windows name when Resolve-IslAccount resolves the credential's name, the name as given otherwise. For a resolved AzureAD\ account the refusal reads "a stored-password task did not start for a Microsoft Entra account on the lab device, with or without the "Log on as a batch job" right; sign the account in and run while it holds a session"; the hint about the right stays for every other account.
• Help and README. The -Credential description of the five harness commands and the README's account section say an Entra account has to hold a session. MAML rebuilt.
• Findings. The table above under "The harness as another account".
• Tests. The task registered for the Windows name with the credential's password; the Entra refusal text, and the right's hint absent from it.

Verification

• Unit and integration suites: 929 pass on PowerShell 7.6.6 (8 skipped: elevation, lab credential); 879 pass on Windows PowerShell 5.1 for the unit suites and two integration files (33 skipped). PSScriptAnalyzer (Error and Warning) is clean; no line over 115 characters; help Markdown validates.
• Lab device, the module run as SYSTEM with the user signed out and its real password: -Credential with the sign-in name no longer fails at registration and reports the Entra refusal after 11 seconds; the Windows name reports the same after 9 seconds. No task and no run folder left behind. Before this change the sign-in name failed with "No mapping" at once (Harness: -Credential finds a Microsoft Entra account's session #6).

Notes

• The password used for the measurement was placed on the lab device for the test and removed afterwards.
• Whether an Entra account can run a stored-password task on any device is not established; only that it did not on this one, joined and enrolled, with the right and without.

[fadwen]

Notes on the lines whose reason the diff does not show.

[fadwen]

Placed before the generic clause, and keyed on the account rather than on the failure code, so an Entra account never receives the hint about the "Log on as a batch job" right: on the lab device granting the right changed nothing, and the hint would send someone the wrong way.

[fadwen]

267011 is 0x00041303, "the task has not run yet", as Get-ScheduledTaskInfo reports it: in decimal.