A job's log uploading slowly holds a deploy long after the job's work is done

Seen on 2026-10-21 in Deploy #511 (run_01m5g7rr0mejebz72xxvcd0dw6), build front (docs), job_01m5g8cg1ee0svfrsj0sbhcp69.

The docs build printed its page list at 22:14:38, but those log lines reached g1t about one a second: chunks stamped 22:30:00 to 22:30:08 still carried 22:14:38 output. The step stayed in_progress for over 23 minutes, where today's other docs builds took 1–2½ minutes. It held core, edge, front and Smoke, and the deploys queued behind it (#513), until the run was cancelled by hand.

Find where the runner or the actions service paces log upload (chunk size, a per-job or per-workspace rate limit, or a retry loop), and why it fell to about 1 line/s. A step should finish when its process ends, with the log catching up after. A slow log must never hold a deploy. Check whether long, chatty steps such as the docs build's per-page output trigger it, and whether other runs today saw the same thing.