This means that the default jobrunner fallback is disabled (which would process jobs during page views), thus
$wgJobRunRate is already set to zero in MediaWiki-Docker (preloaded via its PlatformSettings.php). This helps catch bugs relating to accidental reliance on global state, and more approximate a bit more how jobs run in WMF production.
For all but a single-person wiki, though, MediaWiki recommends a cronjob or continous service for running jobs. Even on shared web hosts, there tends to be an option to schedule cron for this. This is importnat as otherwise the user experience can become quite confusing after a while. E.g. if you have a few extra extensions installed, one edit might queue multiple jobs. These would in turn take at least as many (uncached) pageviews to process. There would also be issues with template edits seemingly not applying to relevant pages, search and category lists being out of date, batch tasks not executing, etc.
To pause the jobrunner in mediawiki-docker specifically, one can run:
mediawiki$ docker compose pause mediawiki-jobrunner
To resume, run
mediawiki$ docker compose unpause mediawiki-jobrunner
Alternatively, a broad
docker compose restart will also ensure that the jobs are running.
There might also be a button to pause/unpause the "jobrunner" container in the Docker Desktop user interface if you use that (on macOS and Windows).