Test definitions: alignment with the API specification and Testing Guidelines #34

Problem description

The test definitions in device-authenticity.feature are not fully aligned with the API definition and the API Testing Guidelines:

• The testing assets require both "a valid IMEI not present in any register" (200 with unknown) and "a valid IMEI that is not found in any accessible database" (404). See Error responses: remove OUT_OF_RANGE, clarify 404, and use the common error responses and examples #29.
• The success scenarios validate the response against #/components/schemas/ImeiStatus (e.g. line 41), while the 200 response is CommonResponseBody and ImeiStatus combined, so lastChecked is not validated. "the response body complies with the OAS schema for this operation and status code" covers the full response.
• The scenarios 01 and 09 require reportedDate to be absent, which the API definition does not state.
• The testing asset for stolen devices requires "a known reportedDate", but scenario 03 does not check it.
• Scenario 10 repeats scenarios 02 to 08; scenarios 12 and 14 repeat checks done in every success scenario.
• The documented 400 OUT_OF_RANGE has no scenario (see Error responses: remove OUT_OF_RANGE, clarify 404, and use the common error responses and examples #29 for its removal).
• No scenario checks that a request body with an undeclared property is rejected with 400 INVALID_ARGUMENT, as stated in info.description.
• The 422 scenario depends on the definition of SERVICE_NOT_APPLICABLE, which is open.

Expected action

Align the test definitions with the points above, and with the changes resulting from #29, #31, #32 and #33.

Additional context

Test definitions are optional for an alpha release and required for a release candidate. To be resolved before the next release after r1.1.