Full Suite Gate: Windows at its 30-minute limit, because every tiny test scan spawns worker processes that re-import GitGalaxy #3913

What happens

The Full Suite Gate's Windows jobs are at their timeout-minutes: 30:

• Run 36335845364: both Windows jobs were cancelled at 98–99% of the suite.
• #3816 (part 3a): scan Japanese, Chinese and Korean mainframe source (EBCDIC cp930/939/935/937/933) #3901's run: windows-latest, 3.9 finished in 29 min 58 s (pytest: 1648 s).

Why

Its --durations=25 on Windows 3.9:

• test_the_oracle_is_sound_on_the_mainframe_seed: 318 s
• Twenty-odd tests/cobol_mainframe/* fixtures: 38–47 s each. Every one is a scan_to_db of a 3–6 file estate.

A scan of one COBOL file, measured on Linux:

The extraction itself took 0.06 s. The rest is process start-up:

• galaxyscope always starts a ProcessPoolExecutor with cpu_count - 1 workers, whatever the file count.
• Under spawn, each worker re-imports GitGalaxy. That takes about 3 s, mostly compiling the language registry; see the follow-up issue on import cost.
• Under pytest-xdist, 4 tests scan at once and each starts up to 3 workers: up to 12 importing processes on a 4-core runner.

The suite runs about 150 such scans, so this cost is O(number of scans) × spawn overhead.

Fix

1. galaxyscope: never start more workers than files. Extract in-process, with the same worker code and no pool, when a scan has 16 or fewer files or GALAXYSCOPE_MAX_WORKERS=1. The in-process path must keep what the process boundary gave:

   • arguments are copies;
   • the root log level and the SIGALRM ReDoS-fuse handler are restored;
   • exceptions arrive through a Future;
   • it runs on the main thread only.

   Proven byte-identical by running both golden masters through the in-process path.

2. tests/conftest.py: under xdist, pin GALAXYSCOPE_MAX_WORKERS=1, because xdist already fills the cores.

3. Raise timeout-minutes to 45, as headroom only.

The macOS failure of test_production_regex_redos_immunity on the same run (dart::func_start "hung") is a wall-clock test on an oversubscribed runner, so it is plausibly the same cause.