[VadaLinux]

Runs the VDLP-49 client against a real FirecREST v2 server for the first time — the
project's demo stack, f7t-appversion: 2.6.0, system fakecluster — and reports what
that found. The client was written against the specification and had never issued a
request.

Based on VDLP-49-firecrest-v2-client, not main, because that branch is still
open in #1 and is what this work builds on; basing on main would replay #1's commits
here. Retarget to main once #1 merges. Not for merge before then.

Outcome

All four commands the issue asked for work: token, systems, submit, status polled
to COMPLETED, download. Getting there surfaced one defect in this client and two in
the demo stack.

Command	Result
OAuth2 client credentials	works — issuer is the launcher on :8025, as configured
systems	works — fakecluster
submit	works — 201 {"jobId":"14"}
status	works, after adding the state call — /metadata has no state
download	works on an explicit output path; 404 on the scheduler's default one

What changed, and why

Submit used the wrong field names. The client sent working_directory,
standard_output, standard_error; JobDescriptionModel spells them
workingDirectory, standardOutput, standardError. FirecREST 2.6.0 accepts both —
its models populate by field name as well as by alias — so this never failed a request
and the fields were being honoured. Submitting the same job both ways produced
identical scheduler-side metadata. It is still worth fixing: that acceptance is an
implementation detail of this version, not a contract, and a server without it would
silently ignore working_directory and run jobs in the user's home instead of the
requested directory — a wrong-directory job, not an error. The unit test asserting the
snake_case wire format was asserting the wrong thing and moved with it.

/metadata carries no job state. It returns jobId, script, and the three
stream paths — nothing else, identically for a queued and a finished job. The issue
asked to poll to a terminal state; with the calls the client had, there was nothing to
poll. State is on the sibling GET /compute/{system}/jobs/{id}. Adds Client.Job
over it, JobState.Terminal() over Slurm's terminal states, and Client.Systems for
/status/systems. An unrecognised state counts as non-terminal, so a caller polls
again rather than reporting a wrong outcome.

The CLI could not name a job's output file, which the stack defect below makes
necessary. submit gains -name, -out, -err.

Two demo-stack defects — documented, not patched

Per the issue's constraints these are reported rather than worked around.

1. An absolute standardOutput is concatenated onto the working directory in the
   metadata response: requesting /home/demo/tmp/snake.out under working directory
   /home/demo/tmp reports /home/demo/tmp//home/demo/tmp/snake.out. The file is
   written correctly; only the reported path is wrong.
2. The default output path does not exist. scontrol reports
   /home/demo/slurm-13.out; the sbatch stand-in writes stdout to
   /var/spool/fakeslurm/13/stdout. Downloading the reported path returns a faithful
   404. This is an artefact of the fake scheduler — the two halves of the stand-in
   disagree — and would not occur against real Slurm.

Confirmed correct, unchanged

Authentication works as written (the issue flagged the issuer as a likely first
discovery; it is not one). ops/download is an octet-stream, handled correctly, and is
not ops/view, so the documented /ops/view size-default defect does not apply here.
ops/upload returns 204 with the client's multipart shape. The max_ops_file_size
limit is real — a 2 MiB download against the 1 MiB limit returns 413, surfaced as an
APIError with the status intact. jobId comes back as a JSON string, not a number;
the client already accepted both and a test now pins both.

Verification

gofmt, go vet, staticcheck and go test -race are clean, and the suite still
needs no running stack. Five unit tests added for the new calls and the terminal-state
predicate.

Not verified: no real Alps system, no real CSCS credentials. fakecluster's
scheduler is a shell script that runs jobs inline, so no job was ever observed
PENDING or RUNNING and the terminal-state logic has only met COMPLETED. Demo
tokens are long-lived; refresh under a realistic ~300 s TTL is untested.

Full transcript, including the raw HTTP behind each finding, is in
docs/verification-v2.md.

The v1 stack was not touched, firecrest-agentic-workbench was not modified, nothing
inside the cloned upstream was changed, and the v2 stack is left running and healthy.