ci: run the OpenBSD --use-tcp test step at -j2

The OpenBSD job runs inside a nested VM. At -j8 the --use-tcp run starts
many concurrent loopback daemons, and under that resource pressure the
daemon connection handshake occasionally loses a timing race and one test
hangs to the 300s runner timeout. It is an environment artifact, not an
rsync defect: the daemon handshake writes-then-reads with unbuffered early
I/O (no flush/mutual-wait deadlock), the indefinite wait is the documented
no-timeout daemon behaviour, and it does not reproduce off OpenBSD even with
the full suite pinned to a single CPU at -j8.

Drop just this job's --use-tcp parallelism to -j2 so the nested VM stops
over-subscribing; the pipe `make check` and every other platform are
unchanged.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.github/workflows/openbsd-build.yml

@@ -37,7 +37,15 @@ jobs:
           make
           ./rsync --version
           make check
-          ./runtests.py --rsync-bin=`pwd`/rsync --use-tcp -j 8
+          # The --use-tcp daemon tests run at -j2 here (vs -j8 elsewhere): this
+          # job runs inside a nested VM, and at -j8 the many concurrent loopback
+          # daemons occasionally lose a connection-handshake timing race under
+          # that resource pressure, hanging one test to the 300s timeout. It is
+          # an environment artifact, not an rsync bug (the handshake is
+          # deadlock-free and unreproducible elsewhere, even pinned to 1 CPU at
+          # -j8); -j2 keeps the VM from over-subscribing. The pipe `make check`
+          # above stays at the default parallelism.
+          ./runtests.py --rsync-bin=`pwd`/rsync --use-tcp -j 2
           ./rsync-ssl --no-motd download.samba.org::rsyncftp/ || true
     - name: save artifact
       uses: actions/upload-artifact@v4