feat: conditional srand48/cs_time_ms startup calls + usesGC infrastructure

[cs01]

feat: conditional startup calls + usesGC infrastructure

Removes two unnecessary calls from binary startup and adds the flag infrastructure needed to eventually gate `GC_init()` + `-lgc`.

What changes

Conditional `srand48()` seeding

Every binary previously called `srand48()` at startup even when `Math.random()` was never used. Now only emitted when `Math.random()` is called.

Conditional `cs_time_ms()` call

`cs_time_ms()` was called unconditionally at startup (used by the test runner). Now only emitted when the test runner is active.

`usesGC` flag infrastructure

New `usesGC` flag on `LLVMGenerator` (and `usesMathRandom` which drives the `srand48` gate). These follow the existing pattern of `number` fields for self-hosting compatibility. The `usesGC` flag is the setup for a follow-up that gates `GC_init()` + `-lgc` — which is the only remaining source of startup overhead vs C.

What's NOT here

Bridge `.o` conditional linking was explored and reverted — the linker already dead-strips unused symbols from statically linked `.o` files, so gating them manually is redundant. The existing `usesHttpServer`, `usesCrypto`, `usesSqlite` flags that gate actual `.a`/`.so` libraries with init code are still valid and untouched.

Startup benchmark (hello world)

Binary	Per-invocation
ChadScript	~1.94ms
C (`clang -O2`)	~1.36ms

Gap is `GC_init()` — gating it requires tagging every `GC_malloc` emit site with `setUsesGC(true)`, then gating `GC_init()` and `-lgc` behind `usesGC`. That's the follow-up.

Implementation notes

• `getUsesMathRandom()` added at END of `FunctionGeneratorContext` interface — inserting in the middle shifts vtable indices and causes a stage1 segfault in the native compiler
• `generateMain()` restructured: body generated first, preamble built after, so `usesMathRandom` is set before the preamble conditional is checked