JobService::scheduleJob() has zero production callers — scheduled jobs may never reach Nextcloud's job list

[rubenvdlinde]

JobService::scheduleJob() has zero production callers. If that is real, it means scheduled jobs are never registered with Nextcloud's job list — and the failure mode is that nothing runs and nothing complains.

What was observed

lib/Service/JobService.php:202 — public function scheduleJob(ObjectEntity $job): ObjectEntity.

Surfaced by hydra gate-57 (orphaned-write-capability) during the
openconnector -> integriq app-id rename (#1533). The gate is diff-scoped
under ADR-020, and the rename touched ~100 lib/Service files, which pulled
this method into scope for the first time.

This is pre-existing, not rename damage. Verified on both sides:

• on origin/development: gate-57 reports it as orphaned, and a whole-tree
  search for callers finds none;
• on the rename branch: identical.

The only references anywhere are the method definition, its }//end scheduleJob()
marker, and JobServiceTest::testScheduleJobSkipsAlreadyScheduledJob. Tests do
not count as production callers, and that test calls the class directly.

For contrast, JobService itself is clearly wired — lib/Cron/JobTask.php:90
calls $this->jobService->run(), and JobsController calls executeJob(). It
is specifically scheduleJob() that nothing reaches.

Why this one matters more than a tidiness finding

scheduleJob() is what stamps a job's jobListId. If nothing calls it, then
nothing ever writes that field, and a job created through the UI would sit in
the register looking correctly configured while never being handed to
Nextcloud's scheduler.

This is the same failure family as the stored-jobClass defect fixed in #1533:
the job does not error, it simply never runs, and the surrounding machinery
reports success. JobService::run()'s per-job catch is unset($e); continue;,
so even a throw on that path would be discarded silently.

How to confirm or dismiss this WITHOUT reading the code first

Observable symptoms if the gap is real:

1. Create a job through the UI with a schedule and enable it.
2. Inspect the stored job object: jobListId stays null/absent.
3. occ background-job:list does not show a row for it.
4. Cron ticks complete and report success; no job_log rows appear for that job;
   whatever the job was supposed to write never appears.

If instead jobListId gets populated and the job runs, then there is a seam
gate-57 does not recognise (a declarative register.d handler entry, an event
listener, or a call built dynamically), and this issue should be closed with that
seam named — and, ideally, @orphaned-write-capability exclude <seam> added so
the gate stops re-reporting it.

Deliberately not fixed in #1533

#1533 is an app-id rename. Wiring up (or deleting) a service method is unrelated
behaviour change and does not belong in it. The method carries
@orphaned-write-capability exclude citing this issue, so the gate does not
block the rename while the finding stays open and visible rather than silenced.