fix(webapp): preserve 422 wire-contract for past-date reschedules

Hoisting `parseDelay` to the route layer (for the buffer-side patch to
encode an absolute Date into the snapshot) inadvertently shifted the
"past date" / unparseable-delay error from 422 → 400. Pre-PR that
validation lived inside `RescheduleTaskRunService.call` (throws
`ServiceValidationError("Invalid delay: …")` → 422); SDK consumers
keying retry / error-classification logic on 422 would have seen a
silent drift.

Return 422 with the same `Invalid delay: <input>` message shape the
service produced. Validation outcome is unchanged (past dates still
rejected); only the status code aligns back with pre-PR behaviour.

Devin follow-up on PR #3756.

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

@@ -44,9 +44,17 @@ export async function action({ request, params }: ActionFunctionArgs) {
   // its PG-side flow; for the buffer-side patch we encode the same
   // wall-clock value so the drainer's engine.trigger sees the intended
   // delayUntil after materialisation.
+  //
+  // Wire-compat: pre-PR the validation happened 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.
   const delayUntil = await parseDelay(body.data.delay);
   if (!delayUntil) {
-    return json({ error: "Invalid delay value" }, { status: 400 });
+    return json({ error: `Invalid delay: ${body.data.delay}` }, { status: 422 });
   }
 
   try {