fix(create,update): standardize duplicate key error handling across endpoints

[Bodeayman]

Related Issue

Closes #63

Problem

When creating or updating an entity with a duplicate unique key (such as name),
the API bubbled up a raw UniqueViolationError directly to the client, resulting
in 400 Bad Request responses that leaked internal database details including
table names, constraint names, and row data from the DETAIL field.

Solution

Introduced a centralized error handling mechanism for uniqueness violations:

• utils.handle_duplicate_error — a new utility function that catches
  UniqueViolationError exceptions from asyncpg
• Detail Parsing — uses regex to safely extract the conflicting key name
  and value from the database error, returning a clean message:
  "An entity with [column] '[value]' already exists."
• Standardized Status Codes — responses now correctly return 409 Conflict
  instead of generic 400 Bad Request
• Full Coverage — applied across all primary entity creation and update routers

Changes Made

• api/app/utils/utils.py — added handle_duplicate_error with regex parsing
• api/app/v1/endpoints/create/ — Thing, Sensor, Location, ObservedProperty,
  FeaturesOfInterest, Network
• api/app/v1/endpoints/update/ — Thing, Sensor, Location, ObservedProperty,
  FeaturesOfInterest, Network

Verification

Scenario	Before	After
POST duplicate name	400 + raw DB error	409 + clean message
PATCH rename to existing	400 + constraint details	409 + clean message
Raw constraint names visible	Yes	No

Before

{
  "code": 400,
  "type": "error",
  "message": "duplicate key value violates unique constraint \"unique_location_name\"\nDETAIL: Key (name)=(location name 1) already exists."
}

After

{
  "code": 409,
  "type": "error",
  "message": "An entity with name 'location name 1' already exists."
}

[lightning-sagar]

why do we need to import 'UniqueViolationError' if we are not using it

[lightning-sagar]

Im a bit unsure about parsing e.detail and returning the extracted column/value to the client. even if we no longer expose the constraint name, we are still deriving the response from internal database error details. would it be safer to return a fixed application-level message like with this name already exists. and keep the detailed exception only for logs?

[lightning-sagar]

could you import from asyncpg.exceptions import InsufficientPrivilegeError, UniqueViolationError as it was used but never import.

[lightning-sagar]

I don’t think we should include type(e).name or raw str(e) in the client response here. That still exposes internal implementation details and can leak database/backend information. For this case, it would be safer to return a sanitized conflict message and keep the original exception only in server-side logs

[lightning-sagar]

if this PR only checks for duplicates before the DB write, i think it is still incomplete for concurrent requests. two requests can pass the pre check at the same time and one will still hit UniqueViolationError. we still need the DB level exception handling path mapped to a sanitized 409 conflict

@ClaudioPrimerano @danistrigaro @massimiliano-cannata, what do you guys think about the concurrent request problem?