test(scheduler-allocator-runner): characterize the seqjob allocator (task 2.1)

12 tests drive the real seqjob plugin through job_alloc_fn and record
today's results, reasons and debits, with switch-stable OOM injection
(sched_make_allocs stub, --wrap of make_host_alloc/make_job_alloc).
Assertions the runner changes on purpose sit in *_today tests.

The characterization showed bug-1893's real effect: vget() returns 0 on
success, so the shared-reason loop (rc <= 0 skip) never records a shared
NO_RESOURCE reason. Bug record and spec wording corrected; the runner
skips only on rc < 0.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

.wolf/buglog.json

@@ -16558,7 +16558,7 @@
       "timestamp": "2026-09-30T03:58:52Z",
       "last_seen": "2026-09-30T03:58:52Z",
       "occurrences": 1,
-      "error_message": "xce_scheduler allocators add spurious resource-0 shared pend reasons (loop reads past unmet list)\n\n**Observed:** found by code reading, so there is no failing run yet. When the shared-resource check\nfails, both allocators add the pend reasons with\n```c\nfor (i = 0; i < ctx->alloc_req.shared.count; i++) {\n    rc = vget(core->resmgr, ((int*)ctx->unmeet.idxs.data)[i], (void**)&r);\n    if (rc <= 0) continue;\n    add_job_preason(reason->reasons, PREASON_NO_RESOURCE, NULL, r->name);\n}\n```\n(`seqjob_allocator.c` `my_alloc`, `parjob_allocator.c` `my_alloc`). The loop\nbound is the number of *requested* shared resources, but `ctx->unmeet` holds\nonly the *unmet* ones, packed at `[0, unmeet.count)` by `unsatisfy_()`\n(`resource.c:152-165`). Its arrays were `calloc`ed with capacity\n`shared.count` (`resource.c:280`), so entries `[unmeet.count, shared.count)`\nare 0.\n\n**Expected:** iterate `i < ctx->unmeet.count` (as the host path does,\n`resource.c:566`), giving one `NO_RESOURCE` reason per unmet shared resource.\n\n**Impact:** wrong pend reason, noise level. When a job requests N shared\nresources and only M < N are unmet, the loop adds N - M extra\n`PREASON_NO_RESOURCE` reasons naming whatever resource has index 0 (if one\nexists), which that job may never have requested. Main reason and allocation\ndecision are unaffected. No out-of-bounds memory access (the tail is inside the\nallocation).\n\n**Found by:** review of the `scheduler-allocator-runner` requirements\n(2026-09-29); the loop moves into the framework runner in that spec.",
+      "error_message": "xce_scheduler allocators never record shared-resource pend reasons (vget rc check inverted)\n\n**Observed:** found by code reading, so there is no failing run yet. When the shared-resource check\nfails, both allocators add the pend reasons with\n```c\nfor (i = 0; i < ctx->alloc_req.shared.count; i++) {\n    rc = vget(core->resmgr, ((int*)ctx->unmeet.idxs.data)[i], (void**)&r);\n    if (rc <= 0) continue;\n    add_job_preason(reason->reasons, PREASON_NO_RESOURCE, NULL, r->name);\n}\n```\n(`seqjob_allocator.c` `my_alloc`, `parjob_allocator.c` `my_alloc`). The loop\nbound is the number of *requested* shared resources, but `ctx->unmeet` holds\nonly the *unmet* ones, packed at `[0, unmeet.count)` by `unsatisfy_()`\n(`resource.c:152-165`). Its arrays were `calloc`ed with capacity\n`shared.count` (`resource.c:280`), so entries `[unmeet.count, shared.count)`\nare 0.\n\n**Expected:** iterate `i < ctx->unmeet.count` (as the host path does,\n`resource.c:566`), giving one `NO_RESOURCE` reason per unmet shared resource.\n\n**Impact:** wrong pend reason, noise level. When a job requests N shared\nresources and only M < N are unmet, the loop adds N - M extra\n`PREASON_NO_RESOURCE` reasons naming whatever resource has index 0 (if one\nexists), which that job may never have requested. Main reason and allocation\ndecision are unaffected. No out-of-bounds memory access (the tail is inside the\nallocation).\n\n**Found by:** review of the `scheduler-allocator-runner` requirements\n(2026-09-29); the loop moves into the framework runner in that spec.\n\nUPDATE (2026-09-30): Found in scheduler-allocator-runner task 2.1 (characterization test test_seqjob_pending_on_short_shared_no_reason_today): the observable effect is not an extra resource-0 reason. vget() (xzarray_get_vec, src/lib/zarray.c) returns 0 on success, and the loop skips on rc <= 0, so it skips every successful lookup and NO shared NO_RESOURCE reason is ever recorded; the over-read tail entries (idx 0) are skipped the same way. Real impact: a job pending on a short shared resource carries no resource reason naming it (main_reason stays 0). The host path (resource.c) correctly skips only rc < 0.",
       "file": "src/scheduler/src/plugins/seqjob_allocator.c, src/scheduler/src/plugins/parjob_allocator.c",
       "root_cause": "TODO: required for fixed/partial",
       "fix": "TODO: required for fixed/partial\n\nVerification:\n- Test: TODO: name + file; RED before the fix, GREEN after\n- Suites: TODO: suite results and build profile\n- Live: TODO: soak/deploy run, or n/a and why",