fix(scheduler): live-verify bug-1790 with a real global mem limit

Adds ug1_global_mem to limits.yaml: a permanent, real GLOBAL limit on
"mem" (a per-host resource, not "slots"), capping ug1's total
cluster-wide mem usage at 5GB. This is exactly the scenario bug-1790
fixed but only unit-tested until now -- no limit in the shipped example
config exercised a global cap on a non-slots per-host resource.

Live-verified via a fresh single-node deploy: 3 jobs submitted as user1
(ug1 member) each requesting rusage[mem=2000000000] (2GB) on queue
normal. Scheduler trace confirms ug1_global_mem correctly matches and,
for the first time, computes a real nonzero job-wide-total wanted value:

  unsatisfy_ resource 36 total 5000000000.000000 inuse 4000000000.000000
    uncomit 0.000000 wanted 2000000000.000000
  unsatisfy_ unmet resource 36 (limit=ug1_global_mem) shortfall
    1000000000.000000

The 3rd job (4GB inuse + 2GB wanted = 6GB > 5GB cap) correctly PENDed
until an earlier job's mem freed up. Deploy config validated with zero
new warnings.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GLfB5uWRdmx2WiZSFC7Fm7

src/configs/limits.yaml

@@ -60,6 +60,18 @@ limits:
     resname: slots
     value: 3.0
 
+    # global cap on ug1's total mem requested across the whole cluster
+    # (bug-1790 regression coverage: a GLOBAL limit on a per-host resource
+    # OTHER than "slots" -- exercises calc_wanted_host_resval_job_totals()'s
+    # generalization of bug-1789's fix to any per-host resource, proven live
+    # rather than left as untested config)
+  - name: ug1_global_mem
+    users:
+      members:
+        - ug1
+    resname: mem
+    value: 5000000000
+
     # migrated from src/controller/sched.c xcesched_push_configs()'s
     # hardcoded limit2_config literal (rshen on the xce queue, per-user/
     # per-queue/per-project/per-host 20% mem cap)