feat: Add-PatServer -Force should overwrite an existing server entry

[tablackburn]

Problem

Add-PatServer -Force does not overwrite an existing server with the same name; it throws:

Failed to add server: A server with name 'plex' already exists

This is surprising because -Force in PowerShell convention typically means "do the thing even if it would normally be blocked" — New-Item -Force, Copy-Item -Force, Set-Content -Force all overwrite existing items. Users hitting an expired token on a stored server reasonably try to re-run Add-PatServer -Force to replace it, only to find that the duplicate-name check at Add-PatServer.ps1:180 fires unconditionally.

Current behavior (per docs)

-Force is scoped to suppressing interactive prompts only (Add-PatServer.ps1:37-42):

• Auto-accepts HTTPS upgrade
• Auto-attempts authentication if server requires it

So technically it works as documented — but the docs themselves diverge from the broader PowerShell convention.

Repro

Add-PatServer -Name 'plex' -ServerUri 'https://example:32400' -Token $oldToken
# ... token expires ...
Add-PatServer -Name 'plex' -ServerUri 'https://example:32400' -Token $newToken -Force
# Throws: A server with name 'plex' already exists

Workaround today on 0.10.3:

Remove-PatServer -Name 'plex' -Confirm:`$false
Add-PatServer  -Name 'plex' -ServerUri 'https://example:32400' -Token `$newToken

(Update-PatServerToken is the proper recovery path, but it's currently unreleased.)

Proposed behavior

When -Force is specified and an entry with the given -Name already exists, replace it in place rather than throwing. Preserve fields the user did not pass (e.g. don't clobber localUri / preferLocal / tokenInVault if the new call omits them) — or document the replace-vs-merge semantics clearly.

If a stricter overwrite gate is desired, an -AllowClobber switch would also work; but the existing -Force already implies "I know what I'm doing" so reusing it matches user expectations.

Notes

• Surfaced while recovering from an expired token; PR feat: Replace 401 errors with actionable token recovery guidance #39 already improves the 401 error message that gets users into this situation.
• Update tests in tests/Unit/Public/Add-PatServer.tests.ps1 to cover the overwrite path (and to assert that omitted fields are preserved, if that's the chosen semantics).