Password decryption commands - Document the remote DAC prerequisite

[andreasjordan]

Draft, to show what the documentation-only option from #10549 actually looks like. The design question on that issue is still open — this PR deliberately does not answer it.

Problem

Up to dbatools 2.7, Get-DecryptedObject opened the DAC itself, from inside the PowerShell remoting session on the SQL Server host (ADMIN:127.0.0.1\<instance>). That is a local DAC: it needs neither remote admin connections nor a reachable DAC port.

PR #10174 removed that path so that a single DAC can be opened early and shared across every command that needs one — SQL Server allows only one DAC per instance, and the per-command open/close pattern was the root of #10040, #9921 and #10475.

The refactor was intended. The side effect was not documented: the requirement changed from "PowerShell remoting to the host" to "PowerShell remoting plus a remote DAC". Reporters hit this as a silent failure, most recently in #10549.

What changed

Help only — no behaviour change, no code touched.

Added to the .DESCRIPTION of the five commands that decrypt passwords directly (Export-DbaLinkedServer, Export-DbaCredential, Copy-DbaLinkedServer, Copy-DbaCredential, Copy-DbaDbMail) a short block naming both connections:

• the DAC, opened from the machine running the command, hence a remote DAC — so the instance needs remote admin connections enabled and its DAC port reachable (TCP 1434 for a default instance, the dynamic port published by SQL Server Browser for a named one)
• PowerShell remoting to the Windows host, to read the service master key from the registry

The three orchestrators (Export-DbaInstance, Start-DbaMigration, Sync-DbaAvailabilityGroup) get a shorter version that also states they open one shared DAC and hand it down, and points at the underlying commands. Sync-DbaAvailabilityGroup already explained the shared DAC; only the network prerequisite was missing.

Every -ExcludePassword parameter now says it is also the way out when the DAC or remoting is unavailable, since the command then needs neither.

Get-DecryptedObject records why it no longer opens a DAC itself, so the next person to read it does not have to reconstruct the history from git.

Two statements that are no longer true are corrected:

• Copy-DbaCredential listed DAC access enabled for local (default) under Requires: — the opposite of what it needs now
• Export-DbaLinkedServer said it "accesses the local registry"; the registry read happens on the SQL Server host, not locally

What deliberately did not change

No code. Whether Get-DecryptedObject should regain a local-DAC-over-remoting path is the question put to contributors on #10549. Reintroducing a second DAC path costs reliability in an area that took several releases to stabilise, so it should be a decision, not a side effect of this PR.

Invoke-DbaDbDecryptObject also opens a DAC but is untouched — it needs one for the encrypted object definitions themselves and has no remoting leg to route through, so the requirement there is inherent rather than a consequence of the refactor.

Testing

• All 9 changed files parse
• Get-Help renders the new text on all 8 commands
• Unit tests for the 9 affected test files pass, no failures and no warnings

Reported and diagnosed by @edbmfo in #10549, whose analysis of the 127.0.0.1 change and its removal was correct in every detail.