a2a peering: un-peering is a clean break (one-sided removal warning, Remove-only revocation, no Peer again, half-pairing guard) #486

Follow-up to the peering poll-mode stack (#400–#408), from Bryant's review of #406 and #400. Part of #399.

Principle (Jackson): un-peering is a clean break. The half-paired state should only ever be a deliberate, warned choice, never an accident. And peering again should cope with whatever half state is left.

2a. Add peer guards against a leftover half-pairing

Today: when Add peer finds a record of this server held only by the other server, for example left by a one-sided removal, PeerIntroductionDialog locks the mode to that record (recordedPeeringChoice), hides "Set up differently", and says "remove the peer, then peer again". But there's no row to remove on this side.

Change:

• Treat a record held only by the other server as a leftover, not a live pairing. The dialog says "Home server still has an old record of this server" and offers the normal fresh setup: the recommendation plus "Set up differently".
• When this client can manage that server, Peer clears the leftover first and then pairs.
• When it can't, the dialog names the server to clear it on.

Removal is unchanged; the guard lives in peering.

2b. One-sided un-peering is warned, not accidental; "Peer again" goes away

1. Remove warns when it can only remove one side. When this client can't manage the other server (not connected, or offline), the confirm says what stays broken. Default is Cancel; the destructive choice is "Remove here only". Suggested wording:

   Home server will keep its side of this peering. This client can't reach Home server to remove it there. Until you remove it on Home server too, Home server will keep trying to reach this server, and its messages to this server's agents will fail.

2. Peer sessions are only revoked through Remove. "Peer: " sessions aren't individually revocable from the Settings → Connections session list; that list points to Peer servers → Remove instead. This removes the accidental half-state, where a revoked credential left this server's record, waiting messages and Exchanges behind. The CLI matches this.

3. Remove "Peer again." With accidental revocation gone, a rejected credential only means the other side deliberately removed its half. In both link modes, the row reads " ended this peering", with Remove as its only action. Peering again is a fresh Add peer, and 2a handles any leftover.

   This deletes:

   • the Peer again button;
   • recordedPeeringChoice and repeeringChoice repair handling;
   • the read-only recorded-address logic in feat(j5): the peering dialog sets up poll mode for you #406.

   It replaces the flow Bryant's review hardened, which is moot under this rule.

4. No credential-expiry handling. Peer credentials are issued for ten years.

This also makes the "revoked polling server looks asleep" case moot (Bryant on #400, AC13). Revocation now only happens through Remove, which deletes the storing side's record.

Docs: cross-device.md AC12 and AC13, the runbook's removal and revocation text, and the user guide's removal paragraph.