fix(webapp): reschedule past-date status is 400 not 422 to match pre-PR wire shape

My previous "preserve 422 wire-contract" commit got the pre-PR
behaviour wrong: the route's catch block (lines 156-159) has always
converted `ServiceValidationError` to status **400**, not 422.
`ServiceValidationError`'s default of 422 is what the class throws,
but this specific route narrows that to 400 in the catch.

Switch the hoisted validation to 400 with the same `Invalid delay:
<input>` message shape the service produced. SDK consumers keying
retry/classification on 400 see no drift; 422-keying consumers were
never receiving 422 from this endpoint to begin with.

Devin follow-up on the previous reschedule wire-contract fix on
PR #3756 — Devin was right that the pre-PR shape was 400, I read the
ServiceValidationError default rather than the route's actual
conversion.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: d-cs

apps/webapp/app/routes/api.v1.runs.$runParam.reschedule.ts

@@ -45,16 +45,18 @@ export async function action({ request, params }: ActionFunctionArgs) {
   // wall-clock value so the drainer's engine.trigger sees the intended
   // delayUntil after materialisation.
   //
-  // Wire-compat: pre-PR the validation happened inside
+  // Wire-compat: pre-PR the validation lived inside
   // `RescheduleTaskRunService.call` (rescheduleTaskRun.server.ts:14-18),
-  // which throws `ServiceValidationError("Invalid delay: …")` on
-  // undefined and surfaces as 422. Mirror that status + message shape
-  // here so existing SDK consumers keying retry/classification logic
-  // on 422 don't see a behavioural drift now that the parse is hoisted
-  // to the route layer.
+  // which throws `ServiceValidationError("Invalid delay: …")`. The
+  // route's catch block below converts that to status **400** (not
+  // 422 — `ServiceValidationError` defaults to 422 but this route's
+  // catch block has always returned 400). Mirror that 400 + message
+  // shape here so SDK consumers keying retry/classification logic on
+  // 400 see no behavioural drift now that the parse is hoisted to the
+  // route layer.
   const delayUntil = await parseDelay(body.data.delay);
   if (!delayUntil) {
-    return json({ error: `Invalid delay: ${body.data.delay}` }, { status: 422 });
+    return json({ error: `Invalid delay: ${body.data.delay}` }, { status: 400 });
   }
 
   try {