fix(jobs): don't overwrite the --stop_after baseline in background-job:worker

[vaenda]

Resolves: #63296

Summary

$startTime was used for two different things:
as baseline for --stop_after and as start time of the currently running job. The variable was reassigned during each loop with each new job in the queue, so the baseline for --stop_after was lost and the worker never terminated.

Renaming the job variable fixes this issue. I applied the patch to my instance and measured it before and after: unpatched the worker was still running after 120s with -t 20s, patched it exits after 20.97s, and after 45.83s with -t 45s.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
  — there is no tests/Core/Command/Background/ directory, these commands
  are not covered by unit tests. Happy to add one if you want the timing
  loop covered.
• Screenshots before/after for front-end changes — n/a, no front-end change
• Documentation has been updated or is not required — not required
• Backports requested where applicable — 34 is affected; leaving the label
  to the maintainers
• Labels added where applicable — maintainers
• Milestone added for target branch/version — maintainers

AI usage

• The content of this PR was partly or fully generated using AI

I had Claude Code work through a large background job backlog on my own Nextcloud instance, and it ran into --stop_after not stopping the worker. It located the cause in the code and suggested the rename. I applied the patch to my instance and measured it before and after: unpatched the worker was still running after 120s with -t 20s, patched it exits after 20.97s, and after 45.83s with -t 45s. The commit carries an Assisted-by: Claude:claude-opus-5 trailer.

[solracsf]

/backport to stable34