fix(core, api): Return 400 for non-mapping YAML input

[sentry]

This PR addresses an issue where submitting non-mapping YAML content to the /optimize-and-export-xlsx endpoint resulted in a generic 500 Internal Server Error instead of a more appropriate 400 Bad Request.

Changes Made:

1. core/nurse_scheduling/loader.py: Modified the load_data function to validate the type of the parsed YAML content. If _load_yaml returns a non-mapping (e.g., a bare scalar string), a ValueError is now raised.
2. core/nurse_scheduling/serve.py: Added a specific except ValueError block in the optimize_and-export-xlsx endpoint's error handling. This block catches the ValueError raised by load_data and translates it into an HTTPException with a 400 status code and a clear, user-friendly detail message.
3. Imported Mapping from collections.abc in loader.py for type checking.

Why these changes:
Previously, when a user submitted YAML content that was a simple scalar (like a plain string) instead of a dictionary, the NurseSchedulingData(**data) call would fail with a TypeError (argument after ** must be a mapping, not str). This TypeError was then caught by a broad except Exception block, leading to a misleading 500 error. By explicitly checking for a mapping type and raising a ValueError, we can now provide a precise 400 Bad Request response, indicating that the client's input format was incorrect, thereby improving API clarity and user experience.

Fixes NURSE-SCHEDULING-5