Mouse Without Borders: failed clipboard transfer permanently kills the clipboard listener; later copies desync the main channel and drop the whole connection

### Microsoft PowerToys version

0.100.2 (identical on both machines)

### Installation method

WinGet

### Running as admin

Yes. Both MWB modules run elevated. The failure also reproduced earlier in the day with one side non-elevated, so elevation state doesn't appear to matter.

### Area(s) with issue?

Mouse Without Borders

### Steps to reproduce

Setup: two Windows 11 machines on wired LAN, direct mode (UseService=false), ShareClipboard=true, TransferFile=false. Both peers are pinned to their LAN IPv4 in the hosts file, so the known IPv6/multipath connection churn is ruled out here. Mouse and keyboard crossing works both directions.

1. Use clipboard sharing normally. At some point a clipboard transfer fails with an exception. I don't have a deterministic trigger for this first failure; on our machines it happened during a day of heavy use, and Windows Clipboard History (Win+V) was enabled on both machines, which #31230 already implicates as a bad interaction.
2. From that moment the machine's clipboard listener is permanently dead. The log shows `The clipboard socket could have been closed. Not listening. You must call the Start() method before calling this method.` and `Cannot access a disposed object.` on every later clipboard event.
3. Every subsequent copy, on either machine, now wedges mid-transfer. The receiving side logs a burst of `MainTCPRoutine.TcpReceive error, invalid package from : 0` (a dozen entries within ~2 ms) followed by socket write failures, and the entire connection drops. The peer side sees `forcibly closed by the remote host`. MWB auto-reconnects in a few seconds, and the cycle repeats on the next copy.
4. Nothing recovers the clipboard listener except restarting PowerToys (or the MouseWithoutBordersHelper process, per the workaround threads).

So a single failed clipboard transfer converts into "any copy kills the whole mouse/keyboard link until you restart PowerToys."

### ✔️ Expected Behavior

A failed clipboard transfer affects that one transfer. The clipboard listener recovers, and the main input channel is isolated from clipboard-channel failures.

### ❌ Actual Behavior

The clipboard listener dies permanently, and subsequent clipboard activity corrupts the main TCP channel, dropping mouse and keyboard crossing entirely.

### Why this happens (source analysis, current main)

Two cooperating defects:

1. In `SocketStuff.cs`, `AcceptConnectionAndSendClipboardData` handles exceptions in the clipboard accept loop with:

```csharp
catch (InvalidOperationException e)
{
Logger.Log($"The clipboard socket could have been closed. {e.Message}");
break;
}
```

The `break` exits the accept loop for good. There is no outer thread or health check that restarts it, so one exception means no clipboard listener until the module restarts. This matches the "Not listening" log line above exactly.

2. Once transfers are wedging, the receiver's `MainTCPRoutine` starts reading unparseable packages, logs the `invalid package` line per package, and after `errCount > 5` closes the socket via `UpdateTcpSockets(..., SocketStatus.Error)`. That part is by-design recovery, but it means clipboard-channel corruption escalates into a full link drop rather than staying contained.

### Log excerpts (machine names genericized)

Dead listener, repeating on clipboard events:

```
07/05 16:02:46.097(18)The clipboard socket could have been closed. Not listening. You must call the Start() method before calling this method.
07/05 04:32:07.211(18)The clipboard socket could have been closed. Cannot access a disposed object.
```

Link death on the next copy (main channel, receiver side):

```
[16:07:56.9213852] [Info] SocketStuff.cs::MainTCPRoutine::1337
07/05 16:07:56.921(29)MainTCPRoutine.TcpReceive error, invalid package from LAPTOP: 0
(repeats ~12 times within 2 ms)
[16:07:56.9226824] [Info] SocketStuff.cs::TcpSendData::504
07/05 16:07:56.922(10)TcpSendData: The socket is no longer connected, it could have been closed by the remote host.
[16:07:56.9305630] [Info] SocketStuff.cs::AddSocket::767
07/05 16:07:56.930(26)New connection from client: [LAPTOP].
```

Also chronic in the same logs, and apparently harmless on its own: `Invalid clipboard format received!` (fires from `Clipboard.cs::SetClipboardData` when format-prefix parsing fails; we saw it for weeks while clipboard sync otherwise worked).

### Workarounds that worked here

1. Restarting `PowerToys.MouseWithoutBordersHelper.exe` restores clipboard for many users in #30259 and #45825 without dropping the link.
2. A full PowerToys restart reliably recovers everything (verified repeatedly on our machines).

### Related issues

This looks like the root cause behind the long-running "clipboard just stops working" family: #45825 (open, Needs-Triage), #39058 (closed as duplicate), #30259 (closed as fixed, but comments from 2026-03-31 report it still reproducing), #26856 (same symptom in 2023), and #48314 shows the same `clipboard socket could have been closed` line on v0.98.0 alongside broader instability. What I haven't found reported anywhere is the second stage: the dead listener turning clipboard activity into main-channel desync and full link drops, which is what makes this bug painful in daily use.

A restart of the accept loop (recreate the listener instead of `break`) would likely turn this from "restart PowerToys several times a day" into a non-event.

### Other Software

Windows 11 Home 26200 (desktop) and Windows 11 (laptop). Windows Clipboard History enabled on both machines during the failures.

Start in SocketStuff.cs at AcceptConnectionAndSendClipboardData and MainTCPRoutine, then inspect Clipboard.cs::SetClipboardData and the logged error paths. Reproduce the failed clipboard transfer with clipboard history enabled and trace whether the listener stops and malformed packages reach the main channel. Done means a failed clipboard transfer recovers or remains isolated without dropping mouse and keyboard connectivity.

Written by the indexing model from the issue text.