POST /api/v1/background_check_logs now requires an application relationship and updates if exists

Breaking Change: application relationship is now required

The application relationship in the request body is now required when creating a background check log. Previously it was optional.

Request Body (under data.relationships):

Required:

• adult-profile -- The user agency profile for whom the background check was performed.
• background-check -- The background check type being logged.
• application -- The application this background check log is for. Accepts types initial-applications or renewal-applications. This is now required for all create requests.

Example relationship block:

{
  "application": {
    "data": {
      "type": "initial-applications",
      "id": "123"
    }
  }
}

Errors:

• 422 Unprocessable Entity -- Returned if the application relationship is missing from the request. The error source.pointer will reference /data/attributes/application.

New: Upsert behavior (update-on-duplicate)

If a background check log already exists for the same adult profile and background check type on the same license (or same application, for renewal-required background checks), the existing log is updated with the provided attributes (e.g., status, notes, completed-at) rather than creating a duplicate.

Response status codes now distinguish the two outcomes:

• 201 Created when a new background check log is created.
• 200 OK when an existing background check log is updated.

Uniqueness is scoped as follows:

• Non-renewal background checks: one log per adult-profile + background-check + license (derived from the application).
• Renewal-required background checks: one log per adult-profile + background-check + application.

If the same adult profile and background check type are submitted with a different license/application, a new log is created as expected.