TST: restore --parallel-threads in free-threaded jobs (lost in #476)

[glaziermag]

Since the #476 CI refactor (May 2025), the free-threaded legs have run every test single-threaded. #564 restored the pytest-run-parallel install via the concurrency dependency group, but the plugin's --parallel-threads option defaults to 1, so installing it alone doesn't engage it — every t leg on master logs:

plugins: run-parallel-0.9.1
Collected 0 items to run in parallel

(e.g. test-pyversions (3.13t) in run 31304272710, 2026-08-09; the plugin's summary section is suppressed at 1 worker, so that collection line is the only log telltale.)

#468 originally wired this up as PYTEST_ADDOPTS=--parallel-threads=4; the #476 composite-action refactor dropped that line, two days before v1.5.0 shipped the first free-threaded wheels — so thread-parallel coverage has been off for the whole period t wheels have been on PyPI.

This PR restores the flag on the pytest step, using the same case() conditional #564 used for the install. Verified on my fork with the matrix trimmed to the Linux t legs:

• as-is: Collected 0 items to run in parallel, 202 passed on both legs — run A
• with this change: Collected 200 items to run in parallel on 3.14t, 121 on 3.13t ("81 tests were not run in parallel because of use of thread-unsafe functionality"), 202 passed on both — run B

Possibly useful context for #574: the flakiness there was observed under fully single-threaded runs.

I found this while auditing CI logs with Claude's help; I verified the #468 → #476 → #564 chain and ran the fork reproductions myself.

[neutrinoceros]

excellent. I don't think we intended CI to only run on a single thread, so I'm aproving now, though I would also like @rgommers' opinion here because I've seen this strategy used deliberately in at least one other package (were multi-threaded runs are only run locally).

[rgommers]

I don't remember dropping it on purpose, and PR description and commit messages don't mention it, so this should be safe to restore.