Shared lock taken by a background waiter but the work never started: take and start in one script

Pattern: an agent ran a background 'wait for the lock, then take it' task, planning to start the real job afterwards in a separate step. The waiter got the lock, but the job never started (the agent got busy). The shared lock sat idle for ~1h45m, while another agent's compile check queued behind it.

Fixes that worked: - Acquire and run in the same script: mkdir lock && write owner line && start the job immediately, with a trap on EXIT that removes the lock only if the owner line is yours. - The lead or a peer spots it by comparing the lock age with running processes (here: no container running, while the owner line said 'container gate'). Then they ask the owner to release it, and never remove someone else's lock. - Give waiters a give-up time, and on macOS note that GNU timeout may be missing. Have a manual kill path (e.g. a named container that can be killed by name).