Stale MP-safety comment asserts a locked OR where code emits a nonlocked OR — safety of gd_spending pend path rests on an unstated, unenforced per-CPU invariant

Summary

The DO_SETBITS header claims 'setbits uses a locked or, making simple cases MP safe' but the macro emits atomic_set_int_nonlocked - a plain orl documented as local-interrupt-safe only, NOT MP-safe. Safe today solely because gd_spending/gd_sdelayed are written only by the owning vCPU's host thread and every live caller is same-cpu (verified; cothreads poison %gs and are barred from vkernel calls; the only cross-cpu-capable setsoftvm caller is #ifdef notyet). The comment inverts the invariant, inviting a future cross-CPU caller to silently lose pend bits (lost setsoftvm = stuck DMA map callback; lost setsofttty = dropped tty flush) - device-level hangs that are very hard to diagnose. Same textual divergence on the pc64 twin. State-the-real-invariant fix. Full interleave enumeration of the bit-then-flag deferral vs machintr's clear-then-drain proven LOSS-FREE under x86-TSO (the DF-5611 concern does not transfer).