Duplicate of #21901 -- both narrow the cron tick() file lock to the scheduling critical section (get_due_jobs + advance_next_run) and release it before job execution, fixing tick starvation while a long job holds the lock. Saturated cluster; also overlaps open #38624 and #27492. #21901 is the earliest open canonical.

Verification: Lock release before job execution — clean concurrency fix

The change correctly moves fcntl.flock(LOCK_UN) + lock_fd.close() from the post-execution finally block to before the job execution loop. The _release_tick_lock() helper with its lock_released guard ensures idempotent release even if called from both the early-release path and the finally block.

Key correctness points:

1. Lock scope is preserved — the lock still guards get_due_jobs() + advance_next_run() (preventing duplicate scheduling), but releases before run_job() starts.
2. No double-unlock — the nonlocal lock_released flag prevents the finally block from calling unlock again.
3. Thread-based test — the test proves that a second tick can proceed while the first tick's job is still running. Without this fix, the second tick would skip due to the held lock.

The fix directly addresses the scenario where a long-running cron job (e.g., a contribution cron with 10-minute git operations) blocks all subsequent gateway ticks, causing newly-due jobs to stay stuck in the past.