SERVER-130333 purposely left mongos memory load shedding out of scope. The main challenge is avoiding returning a retryable error for a partially-applied write/update (a non-idempotent operation).

Claude's suggestion for supporting routers:

First flip the process gate (loadSheddingSupportedOnThisProcess) so a pure mongos is no longer excluded, which starts the RSS monitor and makes mongos merge pipelines — whose $group/$sort already flow through the same interrupt/yield shed checkpoints — eligible; then close the one real gap that made routers unsafe, namely that a router's writes are all remote dispatch (cluster batch writes and $merge/$out) that bypass PlanExecutor::executeWrite and so aren't covered by the current LoadSheddingExemptionGuard window, by opening that same RAII exemption window around the router-side write-dispatch chokepoints (the cluster write executor / write_ops batch path and the $merge/$out write phase) so a partial, non-idempotent cross-shard write can't be shed mid-flight while the read side of a mixed pipeline stays sheddable; this preserves the "automatically complete, correctly-scoped" property of the chokepoint design without an enumerated command allowlist, needs no new decision call sites (the signal and the queryMemoryCheckLoadShed checks are process-agnostic), stays behind the same off-by-default knob, and would be validated by extending query_memory_mongos.js to assert that a memory-hungry mongos merge is shed while an in-flight $merge/cluster write is not. Also be sure to start the monitor thread in mongos_main.