perf(actions): debounce runner heartbeat writes and throttle task picks (#38281)

3 reductions in the DB load generated by many runners polling
`FetchTask`:

**1. Debounce runner heartbeat writes**
Every poll wrote `last_online`, and every `UpdateTask`/`UpdateLog` wrote
`last_active` — while a runner streams logs that is many writes per
second per runner. These are now persisted only when stale enough to
actually affect the active/offline status (`ShouldPersistLastOnline` /
`ShouldPersistLastActive`), using the existing columns.

**2. Throttle concurrent task picks**
A new in-process semaphore (`MAX_CONCURRENT_TASK_PICKS`) bounds how many
runners run the task-assignment transaction at once, so a fleet polling
together cannot stampede the query. Throttled polls retry on their next
poll without advancing the runner's tasks version.

**3. Paginate the task-pick query**
`CreateTaskForRunner` previously loaded every waiting job in the
runner's scope into memory on each poll (no `LIMIT`). Now it pages
through the waiting backlog oldest-first with `LIMIT`, claiming the
first label-matching job.

---------

Co-authored-by: Zettat123 <zettat123@gmail.com>

custom/conf/app.example.ini

@@ -3009,6 +3009,10 @@ LEVEL = Info
 ;SCOPED_WORKFLOW_DIRS = .gitea/scoped_workflows
 ;; Maximum number of attempts a single workflow run can have. Default value is 50.
 ;MAX_RERUN_ATTEMPTS = 50
+;; Maximum number of runners that may run the task-assignment query concurrently, per Gitea instance.
+;; Caps this instance's DB load when many runners poll at once; excess runners retry on their next poll.
+;; In a multi-instance deployment the cluster-wide limit is this value times the number of instances. Default value is 16.
+;MAX_CONCURRENT_TASK_PICKS = 16
 
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;