fix(scheduler): fix limit-plugin usergroup/scope/error-code cascade (gitea#46)

While live-verifying gitea#46, found and fixed a cascade of 5 previously
undetected bugs that together made every usergroup-scoped limit in
limits.yaml silently non-functional:

- Named usergroups/hostgroups (users.yaml/hosts.yaml) were never
  registered into the scheduler's group managers (groupmgr_add() had zero
  production callers), so any limit referencing one by name could never
  resolve real membership.
- An unconfigured limit scope (e.g. no "projects:") arrived as an
  empty-but-present capnp group, not NULL, so build_consumer() built a
  real empty group (matching no one) instead of falling back to "all".
- Three separate call sites conflated key_find()'s negative "not found"
  return with a real error, short-circuiting before ever reaching the
  "instantiate on first use" logic right below them -- the same defect
  class already fixed once before in this codebase (bug-1495).
- Two call sites passed &(sched->core.resmgr) where a plain handle was
  expected, one level of indirection too many, causing RTTI's key_find()
  to reject it as an invalid handle.

All five are live-verified: fresh cluster deploys now correctly match and
instantiate usage tracking for all 7 limits in limits.yaml on every job
submission, reproduced across multiple independent from-scratch redeploys.

A 6th, architecturally distinct issue remains open (bug-1789, logged, not
fixed): sched_fill_limit_requests() computes a job's consumption of a
slots-scoped global limit by reading the wrong request vector, so the
numeric cap itself still never binds. This needs a design decision on
intended cross-scope semantics, not a mechanical fix, so it's left for a
follow-up.

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

src/lib/group.c

@@ -303,6 +303,43 @@ int groupmgr_add(var mgr, xce_group_t* g)
     return rc;
 }
 
+/* bug-1784: registers a cluster config's NAMED group list (e.g.
+ * xce_conf4sched_t.ugroups/hgroups, sourced from users.yaml's top-level
+ * "usergroups:"/hosts.yaml's "hostgroups:") into mgr by name, via the
+ * existing makeGroup(). Without this, a group config's own name is never
+ * added to mgr's kvtab under that name, so any OTHER group config that
+ * references it as a member (e.g. a limit's per-limit consumer group,
+ * plugins/limit.c's build_consumer()) can never resolve it: make_g_member()
+ * falls back to treating the name as a literal, ungrouped member that will
+ * never match a real username/hostname. Callers (e.g. scheduler.c's
+ * sched_init_config()) must call this BEFORE building anything that may
+ * reference these groups by name. */
+int groupmgr_load_configs(var mgr, int count, xce_group_config_t** configs)
+{
+    int i;
+
+    if (mgr == NULL) {
+        return -EINVAL;
+    }
+
+    for (i = 0; i < count; i++) {
+        xce_group_config_t* config = configs[i];
+        xce_group_t*        g;
+
+        if ((config == NULL) || (config->name == NULL)
+            || (strlen(config->name) == 0)) {
+            continue;
+        }
+
+        g = makeGroup(mgr, config, config->name);
+        if (g == NULL) {
+            return -errno;
+        }
+    }
+
+    return 0;
+}
+
 xce_group_t* groupmgr_lock(var mgr, char* name, int op)
 {
     int          rc;