stop orphaed jobs

[giurgiur99]

Fixes #1373

Changes proposed in this PR:

Problem

• Jobs stuck forever in BuildImage / PullImage after a node restart (processJob had no branch for these statuses).
• stopRequested ignored during build/pull (only the RunningAlgorithm branch read it).

Fix

• New activeBuildAborts mapping registered by buildImage / pullImage
• New processJob branch for BuildImage / PullImage:
  • Controller present + stop requested → abort()
  • No controller → orphan -> Failed

[giurgiur99]

/run-security-scan

[alexcos20]

AI automated code review (Gemini 3).

Overall risk: low

Summary:
The PR successfully implements a robust mechanism to track, abort, and identify orphaned pull and build jobs using AbortController and a mapping of active abort handlers. It prevents resource leaks and hanging processes during job terminations or node restarts, correctly cleaning up timeouts. LGTM!

Comments:
• [INFO][bug] Consider a potential race condition edge-case: If checkJob is invoked by a periodic timer exactly after a job's status is updated in the database to PullImage / BuildImage, but right before the asynchronous pullImage or buildImage execution adds the controller to this.activeBuildAborts, it might falsely identify a fresh job as an orphan. Ensuring that activeBuildAborts.set(...) happens before or immediately surrounding the database status update minimizes this risk.
• [INFO][style] Good implementation replacing AbortSignal.timeout with a custom AbortController and setTimeout. This elegantly allows you to handle explicit abort requests (via stopRequested) while preserving the pull timeout limit safety constraint.
• [INFO][performance] Excellent use of the finally block to clear the timer and remove the entry from activeBuildAborts. This guarantees there are no hanging references or memory leaks regardless of whether the Docker process succeeded, failed, or timed out.

LGTM!