fix: Move Add-PatServer vault writes behind ShouldProcess

[tablackburn]

Background

Surfaced during code review on PR #42 (commit cbc4d02). PR #42 fixed the new -Force overwrite path so Remove-PatServerToken runs inside ShouldProcess and is gated to avoid clobbering a freshly-written vault entry. It explicitly did not address the broader pre-existing concern that other vault writes in Add-PatServer happen before ShouldProcess.

Both CodeRabbit and Copilot flagged this independently:

• CodeRabbit thread (resolved with scope deferral)
• Copilot thread (resolved with scope deferral)

Problem

In Add-PatServer.ps1, two vault-write calls run before the ShouldProcess block at the end of the function:

1. The explicit-token path: Set-PatServerToken -ServerName $Name -Token $Token (around line 221).
2. The auth-recovery path: Connect-PatAccount followed by Set-PatServerToken -ServerName $Name -Token $authenticationToken inside the validation catch (around line 293).

When the user runs Add-PatServer -WhatIf or declines -Confirm, neither write is suppressed:

• The token gets written to the vault (or to plaintext on the new server object) even though the configuration file is not persisted.
• For an existing server with -Force -WhatIf, the vault token can be silently replaced even though the in-memory config and servers.json are not updated.
• Connect-PatAccount opens an interactive PIN flow under -WhatIf, which is also unexpected.

ShouldProcess is meant to make -WhatIf a true preview; today, vault state and the user's interactive auth attempt happen regardless.

Proposed approach

• Stage the token storage decision in temporaries during validation (e.g. resolve whether the new entry will use Vault vs Plaintext, capture the token value), and defer the Set-PatServerToken calls until inside the existing ShouldProcess block.
• Defer the auth-recovery Connect-PatAccount + Set-PatServerToken similarly. The validation step can still detect 401/403 and surface a warning; the recovery interaction itself moves behind ShouldProcess.
• Add Pester regression tests:
  • Add-PatServer -Token X -WhatIf does NOT invoke Set-PatServerToken.
  • Add-PatServer -Force -Token X -WhatIf over an existing entry does NOT invoke Set-PatServerToken or Remove-PatServerToken.
  • The 401-recovery path under -WhatIf does NOT invoke Connect-PatAccount.

Out of scope

• The duplicate-name overwrite semantics (-Force) — already handled by PR feat: Allow Add-PatServer -Force to overwrite an existing entry #42.
• Restructuring how Get-PatAuthenticationHeader is fed during validation — the working $newServer object can stay; only the actual vault writes need to move.

Notes

• The auth-recovery path uses $Force -or $PSCmdlet.ShouldContinue(...) for the prompt, which is independent of ShouldProcess for confirmation. Need to verify the prompt-suppression semantics still make sense once the actual write moves behind ShouldProcess.
• Consider whether ConfirmImpact should bump from Low once vault writes are gated, since vault tokens are sensitive.