Pre-allocate lazy first-use storage at startup (worker pool, module loads)

[mgrossmann]

Follow-up to #195, which is closed by the libc370 fix chain (libc370#115/#119). What remains of the mechanism is the class of one-time lazy first-use initializations that land mid-region during traffic, all measured on mvsdev:

• Worker-pool growth: the pool starts at MINTASK and grows under the first concurrent load — 64 K stack per new worker plus bookkeeping, planted mid-traffic (measured: three 24-parallel bursts cost ~290 K, ~70 K, ~4 K before reaching the MAXTASK plateau).
• Module first-load: each configured CGI's first request LINKs it into region storage (~one page for the display modules; splits off holes — measured: first /.dsrv//.dm use cost one page and cut a 32 K block out of the main free region).

Each is bounded and harmless on its own, but all of it lands wherever the region map happens to be when the first load spike arrives. Pre-allocating at startup puts every one of these below the high-water mark before the first request:

1. Start the worker pool at MAXTASK (or add a PREALLOC Parmlib keyword if the lazy default should stay).
2. Touch every Parmlib-registered MOD= once during initialization so the load-module storage is placed while the region is empty.

Priority: hygiene, not a bug — the recurring planter died with libc370#115. Measurements in #195 (2026-08-17/18 comments).