[Bug] Search Endpoint Returns Incorrectly Serialized 'name' Field

[yasandu0505]

Description

The search endpoint ({READ_API}/v1/entities/search) and the detail endpoint ({INGESTION_API}/v1/entities/search) return the same underlying entity data,
but the name field is serialized differently between the two, making it impossible to use a
consistent decoder across both responses.

Observed Behavior

Search endpoint returns name as a JSON-escaped string with raw UTF-8 hex (no protobuf framing):

"name": "{\"typeUrl\":\"type.googleapis.com/google.protobuf.StringValue\",\"value\":\"4D696E6973746572206F66204865616C7468\"}"

Detail endpoint returns name as a proper nested object with correctly framed protobuf bytes:

"name": {
  "value": {
    "typeUrl": "type.googleapis.com/google.protobuf.StringValue",
    "value": "0A124D696E6973746572206F66204865616C7468"
  }
}

Impact

• The name field in the search response is a serialized string instead of a nested object
• The value bytes inside that string are missing the protobuf framing prefix (0A 12),
  which is present in the detail endpoint response
• Any protobuf decoder written against the detail endpoint contract will silently produce
  wrong results (truncated string) or fail entirely when applied to search responses
• Since both endpoints serve the same stored data, the inconsistency is isolated to the
  search endpoint's response layer

Evidence

• The detail endpoint proves the correctly framed bytes (0A12...) are stored correctly.
• The search endpoint is returning a different byte sequence (4D69...) for the same field on the same entity, confirming this is not an INGESTION LAYER issue. Probably an issue with the READ LAYER