fix(scheduler): percent-based limit display shows raw fraction, not percent (bug-1831)

fmt_limit()/fmt_limit_units() formatted a percent-based limit's value
as a bare snprintf(..., "%f%%", limit->val.val) -- echoing the raw
stored value with a literal "%" appended. But xce_limit_val_t.val is
genuinely a 0-1 fraction when percent is set (confirmed end-to-end:
no /100 or *100 scaling exists anywhere in the config->capnp->runtime
pipeline; confirmed authoritative by the original hand-written C
literal this codebase's oldest percent-based limit was migrated from,
.val = 0.2 for a documented "20% mem cap"). A correctly-configured 20%
limit therefore displayed as "0.200000%" instead of "20.000000%" --
misleading, though technically an honest echo of the stored value.

Fixed by multiplying by 100.0 before formatting. Display-only --
update_limit_res_value()'s actual capacity computation was already
correct and is untouched. fmt_limit() (a thin XCE_UNITS_RAW wrapper)
inherits this fix for its own percent-branch output too, a deliberate,
intentional change from its pre-fix behavior for percent-based limits
specifically (its 5 pre-existing direct tests only assert rc > 0,
never the exact percent string, so this is safe).

Updated test_limit.c's percent-mode test fixture from an unrealistic
.val=80.0 to a realistic .val=0.8 (assertion text unchanged, since
0.8*100=80 either way) and test_repl_limit_table.c's own percent test
to expect its shared fixture's arbitrary .val=50.0 constant correctly
rendering as "5000.000000%". RED confirmed via the raw Unity testlog's
:FAIL: lines (the aggregate meson summary masks single-test failures,
a known harness quirk in this project); GREEN confirmed after, both
lib and scheduler suites, 0 Unity FAILs.

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/scheduler/testsuite/test_repl_limit_table.c

@@ -3490,7 +3490,7 @@ test_info_limit_named_non_byte_valued_limit_display_completely_unaffected_by_uni
  * directly; this closes the same gap at the REPL dispatch level, through
  * the real `set units` command and repl_info_limit()'s real
  * translate_units_mode() bridge -- neither of which the library-level test
- * exercises). The limit is percent-based (val.percent=1, 50%) on the
+ * exercises). The limit is percent-based (val.percent=1) on the
  * byte-valued resource "mem" -- deliberately so, since Requirement 6.3's
  * own wording singles out "a limit expressed as a percentage of a resource
  * whose own canonical unit is not bytes" as the case that must never be
@@ -3500,6 +3500,26 @@ test_info_limit_named_non_byte_valued_limit_display_completely_unaffected_by_uni
  * task 9's own per-host byte-valued-percent-limit test already covers for
  * the DIFFERENT, RESOLVED-ABSOLUTE usage amount (Requirement 6.4) -- not
  * re-litigated here.
+ *
+ * Percent-display scale (bug fix, added after Requirement 6 shipped):
+ * `add_configured_percent_limit()`'s shared fixture stores `val.val = 50.0`
+ * as an arbitrary test constant -- but `xce_limit_val_t.val` is genuinely a
+ * 0-1 FRACTION when `percent != 0` (confirmed against the real capacity
+ * computation, `update_limit_res_value()`, plugins/limit.c, which multiplies
+ * this value DIRECTLY against the resource's current value with no /100
+ * anywhere in the pipeline -- traced end to end from
+ * src/configs/limits.yaml through capnp to this function). `fmt_limit_units()`
+ * now correctly renders `val.val * 100` for the percent branch, so this
+ * fixture's raw 50.0 displays as the (visually odd but mathematically
+ * correct) "5000.000000%" -- not because 50.0 means 5000%, but because 50.0
+ * was never a realistic percent-scale value to begin with (a real 50% limit
+ * needs `val.val = 0.5`). The shared fixture is deliberately left unchanged
+ * here rather than "corrected" to 0.5, since many OTHER tests in this file
+ * reuse it for their own accounted/capacity math (which depends on the
+ * capacity computation directly, not on this display fix, and remains
+ * correct either way) -- changing it would ripple into those tests for no
+ * benefit to this one, which only cares about verifying units_mode has zero
+ * effect on the percent line, not about the fixture's real-world realism.
  */
 static void
 test_info_limit_named_percent_limit_own_percentage_value_never_scaled_by_units_mode(
@@ -3530,9 +3550,10 @@ test_info_limit_named_percent_limit_own_percentage_value_never_scaled_by_units_m
     captured_raw
         = capture_dispatch(&sim, "info limit pct_never_scaled_limit");
     TEST_ASSERT_NOT_NULL_MESSAGE(
-        strstr(captured_raw, "mem = 50.000000%"),
+        strstr(captured_raw, "mem = 5000.000000%"),
         "sanity: the configured-setting line must show the real percent "
-        "value under RAW mode");
+        "value under RAW mode (val.val=50.0 * 100, see this test's own "
+        "header comment on the percent-display scale fix)");
 
     handled = repl_dispatch(&sim, "set units human");
     TEST_ASSERT_FALSE(handled);