Never let the doctor judge the job it is running inside

[smjenness]

The doctor's own job name necessarily matches PATTERN, because that is how it is scoped to a campaign, so it has always been inside its own task set. Before 2.9.0 that was harmless: pgrep -x R found no R processes for a bash-and-ssh job, so it never appeared in a probe. Widening the scan to every process carrying a SLURM_JOB_ID (#63) made its own sleep and ssh children visible, and a job whose processes sit at 0% CPU with nothing in D-state is precisely the hung signature #62 taught it to recognise.

Caught on the first campaign to run 2.9.0, within three hours of launch:

[doctor]     41750366: HUNG 0% with 6 proc(s) and none in D-state (idle, not contended)
[doctor]     41750366: CONFIRMED HUNG 0% on node64 (age 71m, restarts 3)
[doctor]        restarts exhausted; leaving it

Ten consecutive confirmations, every one of them jobid 41750366, which was the doctor itself. It never acted only because Restarts=3 already sat at MAX_RESTARTS. Without that it would have requeued itself once per sweep, which on a --requeue doctor means killing and restarting the only thing watching the campaign, indefinitely.

Change

Any probed task whose jobid equals SLURM_JOB_ID is skipped before classification.

Verification

Against the live 64-task campaign, both ways:

• Run by hand with no SLURM_JOB_ID, the doctor's job still appears in the sweep, spared only by the unrelated nproc < MIN_PROC rule.
• Run with SLURM_JOB_ID set to that job, it does not appear at all.
• The 64 real tasks are judged identically in both, and the sweep still ends all tasks healthy.

Version 2.9.1, with a NEWS entry. Already hot-patched into the running campaign's library so the live doctor is not exposed while this is in review.