Give the socket tests a thread pool that can answer them

[SimonCropp]

AttachedViewerTests failed intermittently on CI with "No response for Inline", on a different platform and a different test each run, and never locally.

ServerFixture drives the real ViewerClient, whose send is synchronous, so a test holds a pool thread for the whole exchange while the server needs threads of its own to accept the connection and answer it. Two per exchange, against the four or so a runner starts with. Enough of them at once and the answer waits on the pool adding roughly one thread a second, past the client's three second timeout.

Confirmed rather than assumed. With DOTNET_ThreadPool_ForceMaxWorkerThreads=2 the whole suite fails that way four runs out of four, while the class on its own passes nine out of nine, which is the tell: it needs the rest of the suite competing for the pool. With the floor forced to one and the maximum left alone, the intermittent shape comes back exactly as CI shows it. A send that answers in 26ms unstarved took 516ms with the pool merely busy.

Raising the floor removes the scarcity rather than the blocking. The blocking is real, but it belongs to the client the tray and an attached viewer use, and nothing outside a test host runs dozens of those at once. Five runs of the suite under the conditions that used to fail now pass.