feat(scheduler-core): implement scheduler-side admin request handler (task 9.4)

Implements the scheduler's first request-reply opcode (OPCode_schedAdmin).
sched_handle_admin_request() (handler.c) decodes SchedAdminRequest and
dispatches by action: recordStatus answers synchronously (pure read);
recordStart/recordStop are deferred onto the existing pend_updates queue
(XCE_SCHED_OP_ADMIN_RECORD) since sched_record_start()'s snapshot call
requires the session_active==0 precondition only guaranteed on the driver
thread, not the async request-handling thread. driver.c's
xce_sched_driver_translate_pending_events() performs the deferred action
and sends the reply via a new xcecli_reply_schedadmin() (client.c/client.h),
correlated by seq copied before the original request is freed.

Adversarial review found a genuine cross-thread race: sched_record_status()
read driver-owned recording state (including a pointer the driver thread
frees) from the vtask thread with no lock -- the codebase's first such
race, missed by ASan (doesn't detect races). Fixed with a dedicated
record_lock scoped strictly to in-memory field access, never spanning file
I/O; sched_record_status() now strdup()s under the lock instead of
returning a borrowed live pointer. Verified with a real two-thread
lock-contention test (independently confirmed non-vacuous by removing the
lock and observing the test fail) plus a deterministic use-after-free
reproduction.

26/26 scheduler suite, clang-format clean.

src/include/client.h

@@ -133,4 +133,24 @@ extern int             xcecli_jobinfo(xcecli_ctx_t, uint64_t, xce_job_t**);
 extern int xcecli_reply_fetchfile(xcecli_ctx_t, xce_request_t*, xce_fetchfile_reply_t*);
 extern int xcecli_fetchfile(xcecli_ctx_t, xce_fetchfile_t*, xce_fetchfile_reply_t**);
 
+/*
+ * xcecli_reply_schedadmin: send a SchedAdminReply back over `c`'s
+ * connection in response to a previously-received OPCode_schedAdmin
+ * request (scheduler-core spec, task 9.4, Req 5 AC 10). Mirrors
+ * xcecli_reply_fetchfile() above exactly, with one difference: it takes
+ * the original request's `seq` directly rather than an `xce_request_t*`,
+ * since `recordStart`/`recordStop` defer this reply to the driver thread
+ * (see driver.c's xce_sched_driver_translate_pending_events()), by which
+ * point the original xce_request_t has already been freed by the
+ * request-handling thread (xcectx.c's vtask_entry(), immediately after the
+ * registered handler returns) -- seq is the only field of it the reply
+ * needs (opcode is always OPCode_schedAdmin). `recordStatus` (answered
+ * synchronously from the handler thread, real request still in scope)
+ * uses this same function, simply passing `request->seq` directly.
+ * Returns xce_reply()'s own return value; -EINVAL if `c` or `areply` is
+ * NULL.
+ */
+extern int xcecli_reply_schedadmin(xcecli_ctx_t, uint64_t seq,
+                                   sched_admin_reply_t* areply);
+
 #endif