Remove 409 Conflict from POST /lookup/shells/{aasIdentifier} (create-or-replace behavior)

[aaronzi]

What happens?

For AAS Discovery, POST /lookup/shells/{aasIdentifier} behaves like create-or-replace for asset links.

When calling the endpoint multiple times with the same or overlapping specificAssetId payload, the existing links are updated/replaced instead of producing a conflict.

Minimal example:

BASE_URL="http://localhost:8086"
AAS_ID_ENC="aHR0cHM6Ly9leGFtcGxlLmNvbS9pZHMvYWFzLzc2MDBfNTkxMl8zOTUxXzY5MTc"
PAYLOAD='[{"name":"globalAssetId","value":"https://example.com/ids/asset/7600_5912_3951_6917"}]'

# First call: create
curl -i -X POST "$BASE_URL/lookup/shells/$AAS_ID_ENC" \
  -H "Content-Type: application/json" \
  -d "$PAYLOAD"

# Second call: replace/update (no conflict)
curl -i -X POST "$BASE_URL/lookup/shells/$AAS_ID_ENC" \
  -H "Content-Type: application/json" \
  -d "$PAYLOAD"

Observed behavior: success responses (typically 201, sometimes 204 depending on implementation details), not 409.

The OpenAPI spec currently documents 409 Conflict for this POST operation.

Why is this wrong?

409 Conflict does not match the effective endpoint semantics when duplicate or repeated payloads are treated as updates/replacements.

If the operation is intentionally idempotent-ish or replace-oriented for existing links, then a conflict response is not expected for this scenario.

Keeping 409 in the response contract creates ambiguity for implementers, SDKs, and conformance tests.

How should it be fixed?

Update the AAS Discovery OpenAPI response contract for POST /lookup/shells/{aasIdentifier} by removing 409 if replace/update behavior is intended.

Suggested response set:

• 201 for create/update success

• 400 for invalid requests

• default for generic errors

• I have signed the required Developer Certificate of Origin (DCO) already.

[aaronzi]

Related to #550 and #595