Tasktype endpoint should gracefully handle malformed api_constraints values

Describe the bug
The /tasktype/{task_type_id} endpoint is not robust to unexpected api_constraints values.
In src/routers/openml/tasktype.py, the current parsing assumes a valid JSON string containing data_type. If api_constraints is malformed JSON, already a dict, or missing data_type, the endpoint may fail or behave inconsistently.

To Reproduce
Minimal reproducible setup (data-level reproduction):

1. Ensure a task type exists with at least one input row in the DB.
2. Set api_constraints for that input to malformed JSON, for example:
   • "{bad json"
3. Call:
   • GET /tasktype/<task_type_id>

Also test with:

• api_constraints already stored as a dict/object-like value (if DB layer returns dict)
• api_constraints valid JSON but without data_type, e.g. {"foo":"bar"}

Expected behavior

• The endpoint should return a stable response and should not crash.
• It should accept both legacy JSON strings and dict-like values.
• It should include input[].data_type only when data_type is present.
• Malformed JSON in api_constraints should be ignored gracefully for that field.

Additional context
Proposed fix is to make parsing defensive:

• parse string values via json.loads inside try/except json.JSONDecodeError
• accept dict values directly
• set data_type conditionally using safe lookup

Start in src/routers/openml/tasktype.py at the GET /tasktype/{task_type_id} entry point and inspect how api_constraints is parsed. Reproduce the endpoint with malformed JSON, a dict-like value, and valid JSON without data_type. Done means the endpoint returns a stable response, accepts string and dict values, and includes input[].data_type only when available.