[CT-29] Standardise error response format

[mftee]

Problem

Error responses across the service are inconsistent. Some handlers return a plain HTTP status code with no body, others return a JSON object with an error string, and others return different field names. API consumers cannot reliably parse error responses.

Proposed Solution

Create a unified error response handler inside contract/module/error-handler/ and apply it to all existing endpoints.

Acceptance Criteria

• Defines an ApiError struct with fields: error (human-readable message), code (machine-readable string e.g. HASH_INVALID), and status (HTTP status code as u16)
• Implements IntoResponse for ApiError so it serialises to JSON automatically
• All endpoints in contract/module/ return ApiError instead of bare StatusCode or ad-hoc JSON structs for error cases
• Error codes are defined as constants: HASH_INVALID, HASH_NOT_FOUND, ALREADY_EXISTS, ALREADY_REVOKED, STELLAR_ERROR, INTERNAL_ERROR
• Unit tests verify that each error code serialises to the correct JSON shape
• The validation error helper map_validation_error in lib.rs is updated to use ApiError
• Implementation files live inside contract/module/error-handler/