revert(ci): drop ineffective PYTEST_ADDOPTS xprocess workaround

Reading xprocess source (pytest_xprocess.py) confirms my earlier theory
was wrong: pytest_unconfigure only prints a reminder, XProcess.__exit__
is a no-op for cleanup, and process management only kicks in when a test
actually uses the xprocess fixture (none in this repo do). So
`-p no:xprocess` is a functional no-op and the comment was misleading.

The previous successful Plugin Tests run (25231778987) shows
"test test_pty_command has been running for over 60 seconds" for
plugin-shell rust — only one such warning, meaning it eventually
finished. So plugin-shell has a slow / occasionally-hung PTY test, but
not the deterministic infinite hang I claimed.

Keep the 35m step-level timeout (it's still the right blast-radius cap)
and update its comment to reflect the actual suspected cause.

Author: Shaw

.github/workflows/test.yml

@@ -107,12 +107,6 @@ jobs:
       TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
       TURBO_TEAM: ${{ vars.TURBO_TEAM }}
       TURBO_REMOTE_ONLY: true
-      # Several plugins declare pytest-xprocess as a dev dep but none use it.
-      # Its pytest_terminal_summary hook was the last thing to print before
-      # plugin-tests hung for 33 minutes in run 25234887145, so disable it
-      # globally as a precaution. Safe: `-p no:NAME` is a no-op when NAME
-      # isn't installed.
-      PYTEST_ADDOPTS: "-p no:xprocess"
     steps:
       - uses: actions/checkout@v6
         with:
@@ -133,6 +127,9 @@ jobs:
           no-vision-deps: "true"
 
       - name: Run plugin tests
+        # Cap step well below the 60m job budget so a flaky plugin
+        # (most recently plugin-shell rust PTY tests in run 25234887145)
+        # fails fast instead of burning the whole job's wall clock.
         timeout-minutes: 35
         run: bun run test:plugins