Runner application should allow binding to a specific job ID

Describe the bug
This is half-bug half-feature request (or maybe even a question if this already exists). I am have a bunch of ephemeral runners I spin up in response to events in my repository. This involves spawning a new machine and running the runner script in it. Unfortunately, when the runner script starts it talks to GitHub and gets associated with a job at random among outstanding jobs. The simplest form of this is that if two jobs are kicked off by GitHub (say job ID 1 and job ID 2) at around the same time, then the following steps are annoying to deal with:

1. Receive request from GitHub to start job 1. Begin spinning up VM for job 1.
2. Receive request from GitHub to start job 2. Begin spinning up VM for job 2.
3. VM for job 2 provisions and starts ./run.sh.
4. GitHub associates that VM with job 1, even though I had actually intended for it to be spawned for job 2.

This is possible to work around with very careful locking, such that there is only one machine at a time that runs ./run.sh until I get the "job started" event so I know exactly which machine is associated with which job. But it would be nice if I could just go ./run.sh --jobid [whatever] to ensure that this runner will "bind" to only that job, and not anything else that happens to be waiting for a runner. This would save me significant complexity on my side keeping track of what is in flight.

To Reproduce
Steps to reproduce the behavior:

1. Try to run several jobs at the same time.
2. Have ./run.sh run without external synchronization.

Expected behavior
I'd like for this case to be easy in that each machine I spawn is guaranteed to only service a specific request.

Runner Version and Platform

Version of your runner?
v2.322.0 (or whatever the latest is)

OS of the machine running the runner? OSX/Windows/Linux/...
Linux arm64/x64

What's not working?

My script just gets upset that the machines aren't what it expects.

Job Log Output

Probably not relevant

Runner and Worker's Diagnostic Logs

Also probably not relevant

Start with ./run.sh and trace how the runner claims an available job when multiple jobs are waiting. Determine whether the startup path can accept and enforce a job ID, then verify that a runner started for one requested job cannot service another; the issue provides no specific source file or test to run.