chore(buglog): log bug-1825, limit plugin never registered in any sim-mode driver path

Discovered and independently verified while closing out scheduler-sim-
diagnostics task 5: register_limit() has exactly one call site in the whole
codebase (normal-mode sched_register_plugins()); sim mode's own plugin
bootstrap (sim_bootstrap_picker()) only registers the picker plugin. The
info limit command built across this spec's 5 tasks is correctly
implemented and thoroughly tested but currently inert for a real operator
running xce_scheduler -i/-s <replay> -- it will always report "no limits
configured" regardless of the original recording's actual configuration.
Not fixed -- out of task 5's test-only boundary; recommended as the next
piece of work for this open-ended spec.

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

.wolf/buglog.json

@@ -22421,6 +22421,27 @@
       ],
       "occurrences": 1,
       "last_seen": "2026-09-17T02:45:00Z"
+    },
+    {
+      "id": "bug-1825",
+      "timestamp": "2026-09-17T07:10:00Z",
+      "error_message": "NOT A CRASH -- significant, verified architectural gap discovered while closing out scheduler-sim-diagnostics task 5 (final validation task for the new `info limit` REPL command). The limit plugin is never registered in ANY simulation-mode driver path, so `info limit <name|all>` will ALWAYS report \"no limits configured\"/\"no such limit\" for a real operator running `xce_scheduler -i`/`-s <replay>` against a genuine recording -- even one whose original live run had limits configured and actively enforced. The entire feature built across scheduler-sim-diagnostics tasks 1-5 is correctly implemented, thoroughly tested, and read-only/deterministic as designed, but is currently INERT in real production usage: every positive-display test path (tasks 2-3, showing a limit's configured setting and live usage) only exercises the code via a test-only helper that hand-registers the plugin into core->plugins directly, which has no production equivalent in sim mode.",
+      "file": "src/scheduler/src/sim_picker.c",
+      "root_cause": "register_limit() (plugins/limit.c:609) has exactly one call site in the entire codebase: scheduler.c:605, inside sched_register_plugins(), which is itself called only from scheduler.c:827 -- the normal-mode (controller-connected, live) driver's sched_init() path. Sim mode's own plugin-bootstrap mechanism, sim_bootstrap_picker() (sim_picker.c), exists specifically to register a picker plugin (builtin_fcfs, via plugin_register_core()) for simulation/replay mode, since sim mode deliberately does not run the full normal-mode init sequence -- but it only ever registers the PICKER plugin category. It has no equivalent step for the limit plugin (or, by the same reasoning, potentially other plugin categories registered by sched_register_plugins() that were never audited for this gap). Confirmed via full-codebase grep: register_limit()/sched_register_plugins() are never referenced anywhere under sim.c/sim_loop.c/sim_picker.c/driver.c/repl*.c, and no write into core->plugins occurs anywhere in the sim-mode driver files. This is the same class of gap scheduler-driver-equivalence.md already documents for OTHER driver-parity properties (e.g. bug-1613's sched_account_jobs() gap) -- a sim-mode driver feature silently missing something the normal-mode driver does, discovered only when a REPL feature tried to read state that assumes it.",
+      "fix": "NOT FIXED -- discovered and characterized during scheduler-sim-diagnostics task 5 (final validation task), explicitly out of that task's test-only boundary per its own instructions (a production-code fix found during validation must be reported, not silently patched). Recommended fix: add a sim-mode limit-plugin bootstrap analogous to sim_bootstrap_picker() -- either a new sim_bootstrap_limit_plugin() called from the same place sim_bootstrap_picker() is invoked (sim_loop.c, per that function's own doc comment), or generalize sched_register_plugins() itself to be safely callable from sim mode (auditing whether builtin_fcfs's own registration would double-register if sim_bootstrap_picker() and sched_register_plugins() both ran). Needs a decision on whether the sim driver should register ALL production plugin categories (matching normal mode exactly, closing this gap generally) or add limit-specific bootstrap only (narrower, faster, but leaves the general problem for the next plugin type that needs sim-mode REPL visibility). Also needs the actual config source: sim mode's replay files must carry the original limit configuration if there is to be anything for a bootstrap step to register from -- confirm whether `.replay` files / ReplaySession already embed limit config, or whether that itself is a second, sequential gap. This second question was not investigated in this session -- flagged as the first thing a fix attempt needs to check.",
+      "tags": [
+        "scheduler",
+        "sim-mode",
+        "repl",
+        "limit-plugin",
+        "plugin-bootstrap",
+        "architectural-gap",
+        "unfixed",
+        "discovered-during-scheduler-sim-diagnostics",
+        "driver-parity"
+      ],
+      "occurrences": 1,
+      "last_seen": "2026-09-17T07:10:00Z"
     }
   ]
 }