ci: move api-docs and format back to ubuntu-latest (refs #406)

#390 moved these two onto the `small` lane to dodge a ~29 min queue in the
contended `ubuntu-latest` lane. The queue was real, but the lane was the
wrong place to fix it, and #390's own rationale flagged why:

    Caveat: on an API-touching PR this job does a full `dotnet build`, so it
    is not always a "small" job; capacity 4 absorbs that.

"Capacity 4 absorbs that" held only because nothing enforced the SUM of the
runners' per-job memory caps. Each job container is correctly capped at
--memory=10g, but 6 slots x 10g = 60 GiB sat on a 25 GiB host that also runs
prod media. On 2026-07-17 it went to load 713 with 21 GiB swapped, and
telegraf could no longer get scheduled to report it.

server-management#604 fixes that at the source rather than by shuffling
lanes: the `ubuntu-latest` lane now has 5 slots (ci-runner grown to 48 GiB at
capacity 4, plus a bumblebee overflow slot) against this repo's 5
ubuntu-latest jobs, and the `small` lane is sized for genuinely-tiny jobs.
So the queue #390 was dodging is gone, and these two dotnet jobs go back
where they can actually be given memory.

Note this does NOT by itself shrink the `small` lane's caps: `build`
(Build & push image) still runs there and is the very job #570 measured
pegging 5.999/6 GiB, so that lane keeps a 10g-capable slot either way. The
real unlock is disabling Roslyn's persistent VBCSCompiler in CI (#406) —
7.8 GB RSS observed — which would let every cap drop.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.gitea/workflows/docker-build.yml

@@ -585,9 +585,16 @@ jobs:
     # image, and answers in ~5s. Moving it here (and `format`) also drops `ubuntu-latest` from 5
     # jobs to 3, which shortens the queue for `test`/`migrations`/`functional-e2e` too.
     # This is only possible because `container:` makes the job self-contained — it no longer needs
-    # the runner image to supply .NET/Node. Caveat: on an API-touching PR this job does a full
-    # `dotnet build`, so it is not always a "small" job; capacity 4 absorbs that.
-    runs-on: small
+    # the runner image to supply .NET/Node.
+    #
+    # REVERTED to `ubuntu-latest` (server-management#604 / ersatztv#406). The caveat below the
+    # original #390 rationale turned out to be the deciding factor: on an API-touching PR this
+    # job does a full `dotnet build`, so it is NOT a small job, and "capacity 4 absorbs that" was
+    # only true while nothing enforced the SUM of the lanes' memory caps. It didn't: 6 slots x 10g
+    # on a 25 GiB host drove bumblebee to load 713 with 21 GiB swapped. The `small` lane is now
+    # sized for genuinely-tiny jobs, and #604 grew the `ubuntu-latest` lane instead (ci-runner
+    # 48 GiB at capacity 4 + a bumblebee overflow slot), which fixes the queue at the source.
+    runs-on: ubuntu-latest
     container:
       image: 192.168.1.95:3000/timothy/ersatztv-ci:07048b8
       credentials:
@@ -668,9 +675,11 @@ jobs:
   # a status, so it is safe as a required check).
   format:
     name: Formatting (changed .cs conform to .editorconfig)
-    # `small` lane (ersatztv#390) — 37s of work that was queueing ~29 min in the contended
-    # `ubuntu-latest` lane. See the api-docs job above for the full rationale.
-    runs-on: small
+    # Was on the `small` lane (ersatztv#390) to dodge a ~29 min queue; reverted to `ubuntu-latest`
+    # in ersatztv#406 — `dotnet format` needs the .NET SDK and real memory, so it does not belong
+    # in a lane sized for seconds-long shell jobs. See the api-docs job above for the full
+    # rationale; server-management#604 grew this lane so the queue it was dodging is gone.
+    runs-on: ubuntu-latest
     container:
       image: 192.168.1.95:3000/timothy/ersatztv-ci:07048b8
       credentials: