ployz org rm: 'did not confirm unpairing' gives no reason and a retry that can't succeed when the Server answers for another Cluster#3912

ployz org rm doesn't say why a Server didn't confirm unpairing when that Server answers for another Cluster. Its advice is a bare retry, which keeps failing until you follow the steps only the docs give.

Build: frozen 0.3.17 candidate 99a623f800b349f71a37af96cb91dce2658b7a63, local Cloud, sdk: hit local 348922e9 (2bec842e426d).

Repro

1. One Cloud, two Organizations: A (Servers machine-1, machine-2) and B (machine-3). Organization B's pairing also lists a Server that holds Cluster A's Sealing Key. (Lab: an extra pairing row with the same Machine ID. This is the case #3778 now protects.)
2. In B: ployz org rm B --confirm B, approve it.

Actual

--json lists the Server under servers.unconfirmed with no reason. Re-running the retry line gives the same answer every time. Only Cloud's log says why: Server didn't confirm its removal yet ... the connection was refused: Machine <id> belongs to another Cluster.

The skip itself is right: Server A's cloud and cli-* holders all stayed active. #3778 works.

Expected

docs/user/account/organizations.md says this case waits until you stop Ployz on that Server, forget your Servers and try again. The CLI line could say the Server answers for another Cluster and point at that recipe, as the dashboard docs do, instead of a retry that can't succeed. Following the docs recipe from the CLI (systemctl stop ployz.socket ployz on the Server, ployz server forget --confirm B, the org rm retry line, then start Ployz again) removed Organization B, and Organization A's Server kept every holder.

On v0.3.16

New with #3778. Before it, Cloud didn't skip such a Server: its Clear reached it, a worse outcome.

F: 1 S: 3 F×S: 3

Blocks the 0.3.17 cut: no. It is wording; the documented recipe works.