Fix the model of which job each goroutine runs

An AI explained a Go fan-out loop as "one goroutine per job, each processing its own job". Each goroutine is a closure that reads the loop variable job. Whether every closure gets its own copy of job depends on the Go version, so your team models which job each goroutine really processes before building on the code.

An assistant wrote resolve_captured_jobs(job_ids, run_after_index, go_minor). It is in the editor. It has a bug. Find it and fix it.

Input and output:

• job_ids: the jobs, in loop order. Goroutine k is launched on iteration k, for job_ids[k]. Ids can repeat.
• run_after_index: for goroutine k, the loop iteration the loop had reached when that goroutine ran. It can be shorter than job_ids, and its values can be any integers.
• go_minor: the minor Go version in the module's go.mod file. 20 means Go 1.20.
• Return one job id per goroutine, in launch order: the job that goroutine processed.

Rules the tests check:

• With no jobs, return an empty list.
• Go 1.22 and later (go_minor 22 or more): each iteration has its own loop variable, so goroutine k processes job_ids[k].
• Before Go 1.22 (go_minor 21 or less): every goroutine shares one loop variable, so goroutine k processes the job at index run_after_index[k].
  • When run_after_index has no entry for k, the goroutine ran after the loop finished: it processes the last job.
  • Clamp the index to the valid range: below 0 counts as 0, and above the last index counts as the last index.