Job flow on /v1 with /result/:id and queued state #17

What to build

The template's input -> loading -> results flow uses the /v1 API: a client generated from /v1/openapi.json, multipart upload support, results route standardized at /result/:id (matching the backend's default email link), and a Loading page that distinguishes queued from running.

Part of the pre-work for a repeatable process for building AlphaSynthesis / AlphaSynBio apps (pilot: EZKinetics, live on prod by 2026-12-31).

Acceptance criteria

• Generated /v1 client and sync script; types come from the tool's schemas
• Submit with file upload works against staging with the job-template sample tool
• Results route is /result/:id; email links from B2 land on it
• Loading page shows queued vs processing
• e2e covers submit -> results for the sample tool

Blocked by

• Bring frontend-template to the ezspecificity baseline on Angular 20 #11
• Generic job path: schema-validated job.json in, results.json out, no per-tool code mmli-backend#144
• Report queued separately from processing while a job pod is Pending mmli-backend#143
• Prove /v1 submit, upload and results from a browser origin mmli-backend#146