Incorrect success status codes on Management Interface endpoints

[matlec]

Bug description

The Device Capabilities endpoint returns the wrong HTTP status code, and the code in the docs is mislabeled.

The response table lists 201 OK for a successful write. However, 201 is Created, and OK is 200, so the label is simply wrong.

The bigger problem is that the same 201 covers both cases in "The device capabilities document was added, or updated, successfully." Per RFC 9110, 201 Created is correct only when the request creates a new resource. When a PUT updates a document that already exists, the response should be 200 OK or 204 No Content. As written, a client that updates a device that is already registered still gets 201, which reports a creation that did not happen.

The same wording appears on the Deployment Status endpoint, but there it returns 200 OK. So two write endpoints of the same kind return different codes for the same outcome.

Both POST and PUT target the same /api/v1/capabilities/{deviceId} URI with identical response tables, so PUT already behaves as an upsert.

Proposed fix

Agree on a single convention for the Management Interface endpoints and apply it everywhere. Return the code that matches what happened:

• 201 Created when the request creates a new document.
• 200 OK when it updates a document that already exists.
• 204 No Content for a successful DELETE (this is already fine).

Then:

• Change the 201 OK label to 201 Created in device capabilities.
• Since {deviceId} is the full, client-assigned resource identifier, PUT is the correct method for a create-or-update. Keep PUT as the upsert and drop the redundant POST.
• Apply the same 201/200 rule to Deployment Status so both endpoints agree.

Anything else (optional)

No response