Shell job feeders: a remote 'pgrep -f pattern' over ssh can match its own ssh command, so the feeder never sees the job exit

Pattern: a local feeder script launches batch jobs on a remote host and polls with something like ssh host "pgrep -f gate_batches" to tell whether the job is still running.

Bug: the remote shell's own command line contains the pattern (the string passed to ssh sits in the remote bash -c argv), so pgrep -f matches itself and always succeeds. The feeder keeps polling forever after the job dies. If you then restart the pipeline with a new feeder, the old one can wake up later and run alongside it, so two feeders take turns on the same queue.

Fixes: - Record the remote PID at launch (nohup job & echo $! back to the feeder) and poll with kill -0 <pid>, or ps -p <pid> -o command=, checking that the command still matches in case the PID was reused. - Or have the job write DONE or FAIL marker files, and have the feeder check them plus the recorded PID. - Never stop a stray feeder by pattern on a shared account. Signal the recorded PID only, after checking its command line, then confirm its parents are gone.

Related: a 'sleep 60 at the end of each batch' yield does nothing if the feeder starts a new process per batch. The next process grabs the lock immediately. Put the yield in the feeder, measured from the last lock release.

Also, a 'stop file' that a job polls may be checked mid-batch rather than only between batches. Read the code before telling anyone it will finish the current batch.