feat(apiserver): expose PEND reason end-to-end (scheduler → API)

The pending_reason field was declared on models.JobInfo but never populated:
scheduler computed PEND reasons and the controller stored them on
job->pend_reasons, yet the data stopped there. Two gaps closed:

1. controller/apiserver.c: apiserver_job_hook_fun now handles
   HOOK_DETAIL_SETPREASON by pushing the updated job to API servers (reusing
   apiserver_job_update_fun). Without this, a job whose PEND reasons change
   never reached the API server — only JOB_NEW/UPDATE/START/EXIT events did,
   and setpreason fired none of those.

2. backend/convert.go + convert_pure.go: cJobToModel / rawJobToModel now
   extract xce_job_t.pend_reasons (main_reason + host/res reasons) and
   marshal them into models.JobInfo.PendingReason as JSONB. models/jobs.go:
   pending_reason added to JOB_DEFAULT_COLUMN so default job queries return
   it (it was only in JSONBJFields, never selected).

Verified live on t1/t2/t3: a job with resreq "type == nosuchhost" stays
PEND and returns
  "pending_reason":{"main_reason":0,"host_reasons":[{"host":"t1","reason":3},
   {"host":"t2","reason":3},{"host":"t3","reason":3}]}
(main_reason=3 PREASON_MATCH_FAIL per host) via both /jobs list, /jobs/:id
and the SSE stream. 4 new unit tests (rawJobToModel pendReason marshal +
name mapping), all apiserver backend tests pass.

Co-Authored-By: Claude <noreply@anthropic.com>

src/controller/apiserver.c

@@ -414,6 +414,14 @@ static int apiserver_job_hook_fun(int type, int situation, int detail,
         return apiserver_job_fail_fun(type, situation, data, ap);
     case HOOK_DETAIL_JOB_RUSAGE_UPDATE:
         return apiserver_job_rusage_update_fun(type, situation, data, ap);
+    case HOOK_DETAIL_SETPREASON:
+        /* The scheduler pushed new PEND reasons via setpreason and the
+         * controller just stored them on the job (set_preason). Push the
+         * updated job to the API servers the same way a JOB_UPDATE does —
+         * otherwise the API servers keep the job without pend_reasons for
+         * its whole PEND lifetime (the job's own state never changed, so no
+         * JOB_UPDATE fires) and the pending_reason field stays empty. */
+        return apiserver_job_update_fun(type, situation, data, ap);
     }
 
     return 0;