Don't silently mark TI FAILED when state-update payload exceeds column type

[1fanwang]

Same class of bug as #66888 but on the execution-API side. Walking through our LinkedIn DI cluster's (1406, ...) traces, we found two task-instance routes that catch broader-than-DataError exceptions and swallow the DB rejection before any global handler can see it. One returns an opaque 500; the other silently reroutes into a 'mark TI FAILED + return 204' branch — which is worse, because the worker thinks state update succeeded while the server has already marked the task FAILED.

Two execution-API routes — PATCH /task-instances/{id}/run and PATCH /task-instances/{id}/state — wrap their DB-touching code in catches broader than DataError. When a worker submits a payload with an oversized field (note, rendered_map_index, external_executor_id, extra), the DB rejects with DataError, the local catch fires first, and the user-visible result is wrong in two distinct ways:

Two except SQLAlchemyError: catches (in ti_run at line 305 and in ti_update_state at line 465) re-raise as HTTPException(500, "Database error occurred") — opaque 500 with no hint at the column or remediation. One broader except Exception: (in ti_update_state at line 425) reroutes into a "mark this TI FAILED + return 204" branch. That last one is worse than an opaque 500: the worker thinks the state update succeeded, but the server has silently marked the task FAILED — state corruption with no signal the request was invalid.

All three swallow DataError before the global handler from #66888 can see it, so registering the handler alone does not fix these routes.

This PR adds except DataError: raise before each of the three broad catches so the user-payload rejection bubbles to the app-level handler and the caller gets the actionable 413/422 instead. The SQLAlchemyError → 500 and Exception → mark-FAILED fallbacks for unrelated unexpected errors stay intact.

End-to-end against PATCH /task-instances/{id}/state driven through TestClient(cached_app(apps="execution")) with the underlying state-update raising the same DataError MySQL would raise on an oversized note. Three states:

--- BEFORE (upstream/main) — no handler, no DataError catches ---
  HTTP 204
  body: (empty)
  Worker thinks state update succeeded; server silently marked TI FAILED.

--- MIDDLE (only #66888 applied — handler registered, no DataError catches yet) ---
  HTTP 204
  body: (empty)
  Same silent-FAILED behaviour. Registering the handler doesn't help — the
  local except Exception: at line 425 still eats the DataError first.

--- AFTER (this PR + #66888) ---
  HTTP 413
  body: {"detail":{"reason":"Payload exceeded database column limit",
                   "orig_error":"(1406, \"Data too long for column 'note' at row 1\")",
                   "message":"Database rejected the payload. Reduce the field size, or
                              your operator may widen the column type (e.g. MEDIUMTEXT
                              / LONGTEXT on MySQL)."}}
  DataError reaches the app-level handler. TI stays in its original state.

The MIDDLE state is load-bearing — it shows #66888 alone is not enough for this endpoint, which is the whole reason this PR exists.

Three catches in one file, same routes, same fix shape (except DataError: raise before the existing catch), 12 lines of additions total. Read naturally together as "let DataError bubble through the task-instance update routes." Independent of #66888 in merge ordering — each PR is useful on its own, but the user-visible 413 only lands when both are applied.

Closes (partially) #66889.