Add the integration test suite

[BiosSystem]

Track 3 of the v3.4.0 plan. Unit tests exercise functions in isolation; these run WinSwift.ps1 as a real process, which is the only way to cover startup guards, parameter binding, config loading and exit codes together.

That difference already paid for itself: this work found the admin guard bypass fixed in #12. Three releases of unit tests and static validation never caught it, because none of them ran the script.

Risk tags

Every Describe carries one tag, chosen by what it can do to the machine:

Tag	What it does	Safe on
ReadOnly	Exercises -Verify, which reads state and exits before applying anything	Anywhere, including a workstation
DryRun	Asserts -DryRun writes nothing. A regression would write here	Ephemeral machine: CI or Sandbox
Mutating	Deliberately applies changes	Windows Sandbox only

Nothing beyond ReadOnly runs unless asked for.

Coverage

• VerifyContract.Tests.ps1 pins the -Verify exit codes and profile parsing. Every case is deterministic on any machine, which took some care: whether a real tweak is applied depends on host configuration, so none of these assert on one. The machine-independent cases are an exempt-only profile (proving NotApplicable never fails a run, end to end), an unknown feature, an empty profile, a missing path, and an app id that cannot exist.
• DryRunSafety.Tests.ps1 proves -DryRun reaches the apply pipeline and still changes nothing, asserting against the exact values the feature would write, read from its .reg file.
• ApplyRoundTrip.Tests.ps1 applies a registry-backed feature and checks both the verification verdict and the individual values underneath it, so a partially applied .reg cannot pass as compliant.
• RollbackContract.Tests.ps1 is the executable spec for Track 1. Rollback does not exist yet, so the block skips itself until InvokeChanges.ps1 references Restore-RegistryBackupState, then activates on its own. It pins the failure policy from section 3.2, including the load-bearing case that an app removal failure must not trigger rollback.

Writing that contract first is the point: Track 1's open decisions are now assertions rather than prose.

Two findings, recorded rather than papered over

Undo cannot be tested, so plan scenario 2 is not writable. WinSwift.ps1 initialises $script:UndoParams to an empty hashtable, and the only code that ever populates it is Scripts/GUI/Show-MainWindow.ps1. Invoke-UndoFeatures exists, the per-feature RegistryUndoKey metadata exists, and all 112 features declare undo text, but nothing on the command line can select a feature for undo. The test is present and skipped with the reason inline. The larger problem it stands in for is that unattended deployments cannot revert either.

CI runs more than section 5.2 expected. The plan assumed CI would be limited to non-mutating cases. In practice the windows-2025 runner is build 26100 and runs elevated, so it clears both the version gate and the admin guard, and ReadOnly and DryRun both run there. Sandbox is still needed for Mutating, since Server 2025 has no Start menu start2.bin and a limited Appx stack.

Sandbox harness

Sandbox/WinSwift-Tests.wsb maps the repository read-only so a mutating test cannot modify the working tree it was launched from. The bootstrap copies it somewhere writable, installs Pester, and runs the full suite. Everything is discarded when the window closes.

Three defects CI found in the suite itself

1. Pester only discovers *.Tests.ps1 when handed a directory. The files used the Test-*.ps1 convention from Tests/Unit, which works there only because CI invokes each by explicit path.
2. The resulting failure passed as green. Invoke-Pester threw, the empty result made $result.FailedCount null, and $null -gt 0 is false. A suite that discovers nothing now fails.
3. Three files failed at discovery: Pester evaluates -Skip: during discovery, but Test-IsElevated was only dot-sourced in BeforeAll. Resolved in BeforeDiscovery instead.

Static validation covers 110 files, up from 103.