Add a Jobs page: upload a sliced file, watch it queue, delete it

The console could watch and control printers but not give them work. The
Jobs page uploads a .3mf/.gcode: it creates the job (POST /jobs), PUTs the
file straight to the presigned storage URL with a progress bar, and lists
the farm's jobs, polling every 5s since there is no job push channel yet.
The scheduler then starts it on the next idle printer, so there is no Start
button - a queued job IS the request.

Deliberate details: the PUT carries no Authorization header (the URL is
presigned and an uncovered header makes storage reject it) and the same
Content-Type the URL was signed for; a failed upload deletes the job row
it just created, so no queued job waits for a file that never arrives;
only queued/uploading jobs offer Delete, matching what the backend allows.

JobUpload and JobList live in @continuum/ui and take the API calls as
props, like the printer card. A shared apiErrorMessage() replaces the
inline copy on the fleet page.

Checked in real Chrome against the live stack with job dispatch OFF: upload
to the real bucket (57 bytes landed intact), listed as queued, still queued
after a scheduler tick, Delete clears it, no page errors; the test object
was removed from the bucket afterwards. pnpm -r typecheck is clean.

apps/web/composables/useApi.ts

@@ -41,3 +41,13 @@ export function useApiFetch() {
     });
   };
 }
+
+/**
+ * A sentence for a failed API call. The backend's `{ error: { message } }`
+ * body is what explains a 403 (a viewer cannot do this), a 409 or a 502, so
+ * it is surfaced instead of a bare "fetch failed".
+ */
+export function apiErrorMessage(err: unknown, fallback: string): string {
+  const body = (err as { data?: { error?: { message?: string } } }).data;
+  return body?.error?.message ?? fallback;
+}