ntdll iOS: opt-in MADEIRA_SYNC_LEAN drops the SRW history ring and WaitOnAddress counters

Problem ios_srw_note bumps one process-wide counter (ios_srw_ring_idx) on every SRW acquire/release, and RtlWaitOnAddress/RtlWakeAddressAll/RtlWakeAddressSingle bump one more each (ios_xp_nt.woa_*). In Dark Souls III on an iPhone Air that is 170–190k SRW releases a second (wake1 ~55k/s + wakeAll 115–137k/s in [xp-api]) from up to 8 threads on both core types, i.e. roughly 0.5M interlocked increments a second on a few shared cache lines. These counters only feed diagnostics.

Change Opt-in MADEIRA_SYNC_LEAN=1 skips the SRW history ring and the three WaitOnAddress counters. Locking is unchanged. The cost is diagnostic only: [srw] park dumps lose their holder history and [xp-api] shows WaitOnAddress/wake1/wakeAll as 0. The variable is read once in loader_init, next to the heap policy (environment ready, no application threads yet); one [sync-lean] log line when on. Off by default.

Tested (iPhone Air, iOS 27.2, Dark Souls III)

• The switch did what it says: [sync-lean] was logged and [xp-api] showed WaitOnAddress 0/s wake1 0/s wakeAll 0/s for the whole 12-minute session; no freezes.
• Heavy-scene frame rate ([gpu-perf] windows with > 300 draws/frame) went 21.5 → 36.7 fps median (p10 15.2 → 28.8; 32–34 fps after thermal throttling), but that run also turned on MADEIRA_TLS_X64 (#50), Madeira's MADEIRA_THREAD_QOS (willfaust/Madeira#401) and two DXMT switches (willfaust/dxmt#43, willfaust/dxmt#42). With the counters off there is no counter for this change's own saving; my estimate of 1–3 % of process CPU is not measured.
• On the device the variable was read from a different place (this was stacked on #50); this PR moves the read to loader_init so it stands alone. That move is compile-tested only (sync.c and loader.c with the arm64ec toolchain).

🤖 Generated with Claude Code