fix(omp): set OMP_NUM_THREADS from physical cores on every platform

[ThefloorMiner]

On Linux, OMP_NUM_THREADS is never set, so libgomp uses nproc — logical cores. On an SMT host that is a 2× over-subscription, and it costs 41 % of decode throughput.

The project already knows this. physical_cpu_count()'s own docstring says it:

Per-expert matmul regions are tiny and back-to-back; two SMT siblings share one AVX-512 unit and contend, so logical (SMT) counts over-subscribe and hurt throughput. We want true physical cores.

The function is correct and works on Linux. env_for() just calls it only inside if sys.platform == "win32".

And glm.c's self-exec block does not cover the gap: it sets OMP_WAIT_POLICY and GOMP_SPINCOUNT but never the thread count, and it skips itself entirely when COLI_CUDA or COLI_METAL is on — i.e. exactly the configuration where the CPU still carries every non-resident expert. The comment in env_for describes the Windows tuple as "parita' col tuning OMP self-exec di glm.c", but on this one variable the Windows path goes further than the C path rather than matching it.

Measured

GLM-5.2 744B (429 GB) on 4× RTX A6000 + EPYC 7402P (24 cores / 48 threads), CTX=32768, greedy, 64 tokens, .coli_usage restored byte-for-byte before each run. routed CPU is the PROF=1 P0-EXEC counter:

OMP_NUM_THREADS	routed CPU read	decode	per thread
4	6.48 GB/s	1.28 tok/s	1.62 GB/s
8	12.50	1.97	1.56
16	23.97	2.63	1.49
24 (physical)	30.10	2.90	1.25
48 (logical)	17.35	2.06	0.36

Two things this says:

• The path parallelises correctly. Near-linear from 4 to 24 threads, ~1.5 GB/s per thread. This is not a serialisation bug.
• 48 threads read slower than 16. Per-thread throughput falls 3.5× once both siblings of each core are running the same int4 GEMV. The host's 8-channel DDR4-2400 sustains ~85 GB/s, so 17.35 GB/s at the default is 20 % of the machine.

+41 % decode on this host from the default alone.

The change

OMP_NUM_THREADS moves from the Windows-only tuple to the shared path in env_for(), still behind COLI_NO_OMP_TUNE. Verified on both platforms:

	Linux (EPYC 24c/48t)	macOS (M5, 10c)
default	24 (os.cpu_count() = 48)	10 (= 10)
explicit OMP_NUM_THREADS=7	7	7
COLI_NO_OMP_TUNE=1	unset	unset

Windows behaviour is unchanged — same guard, same value, just hoisted.

Second change, required by the first. physical_cpu_count() gains a Darwin branch using sysctl -n hw.physicalcpu. macOS has no lscpu, so now that this patch calls the function on every platform, macOS would otherwise hit the fallback and print an over-subscription warning on hardware that has no SMT at all. With the branch it returns 10 on an M5 and stays quiet.

What I have not verified

• One SMT host. The measurement is Zen 2 with AVX2 and no AVX-512. The docstring's reasoning is about a shared vector unit, so I would expect the effect to be at least as large on AVX-512 parts, but I have not measured one. On a non-SMT host the change is a no-op by construction (physical == logical).
• Metal. I changed a shared path and the Metal backend also skips the C-side OMP block, so it is in scope, but my only Apple hardware is an M5 with 32 GB — too small for a run that would show anything.
• I did not touch glm.c. A bare ./colibri invocation still gets nothing, and arguably should. That is a larger change — it needs a physical-core probe in C — and I would rather land the wrapper fix, which covers coli run, coli chat and coli web, than bundle the two.

Happy to run any additional sweep on the A6000 host; it is set up for this and .coli_usage snapshot/restore is scripted.