An unread exit code is unknown, not success

[abhi18av]

Problem

When a task's .exitcode file cannot be read, defineExitCode() falls back to
scanning the Nomad task events and returning the first integer exitCode it
finds. Nomad leaves ExitCode at its zero value on every event that is not a
task exit, so an allocation that fails before the task body runs looks like
this — captured from an image-pull failure on Nomad 1.11.2:

event type	ExitCode	message
Received	0	Task received by client
Task Setup	0	Building Task Directory
Driver	0	Downloading image
Driver Failure	0	Failed to pull image
Not Restarting	0	Policy allows no restarts

ClientStatus=failed, Failed=true, and no .exitcode written anywhere. The
scan returns 0 from Received.

The caller reads a 0 as the worker reporting success and uses it to override
Nomad's own alloc-state failure. Nextflow is therefore told the task succeeded,
looks for outputs that were never produced, and raises:

Missing output file(s) `ri_summary.tsv` expected by process `CHECK_DB`

That message points at the process script, which was correct. The real failure —
an allocation that never started — had already been reported by Nomad and was
discarded.

This is not a race. Any allocation failing before the task body runs is read as
success, deterministically.

The comment above the caller claimed a missing exit file could not spuriously
suppress, "because defineExitCode returns Integer.MAX_VALUE when it couldn't
read any signal". That holds only if the events fallback does not exist.

Fix

Only accept a code from an event that represents the task terminating, which is
the sole case where Nomad populates ExitCode with a real value. Everything
else falls through to MAX_VALUE, so the failure propagates and
failureMessage surfaces the allocation's own events.

The genuine case the fallback served still works: a worker killed before it
could write .exitcode, where Nomad recorded the real code on Terminated
(the existing exitCode: 143 OOM coverage still passes unchanged).

Also tracks where the value came from, so the warning stops attributing an
events-derived code to local .exitcode. That mislabelling is why the original
report read as self-contradictory: the log said the file was unreadable and then
quoted a value from it.

Effect

Same pipeline, same cluster, one process whose container image does not exist:

Before

ERROR ~ Error executing process > 'NEVER_RUNS'
Caused by:
  Missing output file(s) `ri_summary.tsv` expected by process `NEVER_RUNS`
exit: 0

After

WARN  [NOMAD] Cannot determine exit status for task: `NEVER_RUNS`
ERROR ~ Error executing process > 'NEVER_RUNS'
Caused by:
  [NOMAD] Task failed in Nomad state dead. Task received by client |
  Building Task Directory | Downloading image |
  Failed to pull `abc-cluster/this-image-does-not-exist:none`: Error response
  from daemon: pull access denied … | Policy allows no restarts
  [NOMAD] Inspect job 'nf-d54beae7-…-NEVER_RUNS', allocation 'b6f10031-…',
  node 'client_dev'. Allocation API: http://127.0.0.1:4646/v1/allocation/…

Tests

Two cases, both using the real five-event sequence above:

• defineExitCode returns MAX_VALUE rather than 0 when the allocation never ran
• the reconciliation surfaces the Nomad failure instead of suppressing it, and the
  error names the pull failure

The first commit adds them as reproducers failing against current behaviour; the
second fixes it.

Full suite: 455 tests, 0 failures.