fix(config): night_mem_pct's percent value was 100x too large (bug-1832)

night_mem_pct (resname: mem, percent: true) had value: 50, but
xce_limit_val_t.val is a 0-1 fraction convention when percent is set,
not a 0-100 number (see bug-1831 for the full pipeline trace). As
configured, its actual capacity computed as 50x (5000%) the resource's
current value -- a cap that could never realistically be exceeded by
any actual demand, making this limit functionally dead in any real
deployment.

night_mem_pct was authored directly in YAML for a docs/example config
with no C-literal ancestry to cross-check against, unlike limits2
(migrated verbatim from a hand-written C literal .val = 0.2 for a
documented "20% mem cap") -- it used the human-intuitive but incorrect
0-100 scale instead.

Changed value: 50 to 0.5. This is a real behavior change, not just a
display fix: night_mem_pct will now actually constrain the night
queue's mem usage at 50% for the first time in any deployment using
this config.

Discovered during live manual verification of scheduler-sim-diagnostics
Requirement 6 against a real deployed cluster.

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

src/configs/limits.yaml

@@ -19,13 +19,17 @@ limits:
     value: 4
     per_user: true
 
-    # queue-scoped memory cap, percentage of total mem resource
+    # queue-scoped memory cap, percentage of currently-available mem resource
+    # (bug-1831: percent-based value is a 0-1 fraction, not a 0-100 number --
+    # 0.5 = 50%, matching the convention limit2/limits2's original hardcoded
+    # C literal established; the previous "value: 50" here silently computed
+    # 5000% of the resource, a cap that could never actually bind)
   - name: night_mem_pct
     queues:
       members:
         - night
     resname: mem
-    value: 50
+    value: 0.5
     percent: true
 
     # host-scoped cap, applied per host in hg1