Stored XSS via missing XSS safety check in Admin2 Pages API partial validation

A non-superadmin editor with page editing privileges can send a `PATCH /pages` request containing an XSS payload (e.g., `<img src=x onerror=alert(1)>`) in the page Markdown content. Because the partial-field validation path in `validateChangedFields()` only ran `Validation::validate()` and skipped `Validation::checkSafety()`, the payload was persisted unsanitized. When any user (including an admin) views the affected page, the stored script executes in their browser session.

The vulnerability resides in `AbstractApiController.php` within the `validateChangedFields()` method. This method validates partial field updates submitted via the Admin2 API (e.g., `PATCH /pages`, user and config saves) but never called `Validation::checkSafety()`, so `Security::detectXss()` was never enforced before saving. The patch adds the missing XSS safety check to this partial-validation path.

The patch adds a call to `Validation::checkSafety()` inside `validateChangedFields()` in `AbstractApiController.php`, iterating over the result and appending any safety-check errors to the validation error list. This mirrors the behavior of the full blueprint validator (`BlueprintSchema::validate()`) which already runs `checkSafety()` per field. The fix honors `security.xss_whitelist` (admin.super) and per-field `xss_check: false`, so trusted fields are not over-blocked. A regression test in `BlueprintValidationTest.php` confirms that the XSS payload is rejected while benign Markdown and fields opting out of the check still save correctly.