fix: chat message API responses returning fields undeclared by their types - #42115

Proposed changes (including videos or screenshots)

REST response validation for the API only runs under test, and it passes today for the wrong reason: typia 9.7.2 emits open object schemas (no additionalProperties: false), so AJV silently accepts fields the response types never declared. Once typia moves to closed schemas, the server's own chat message responses would start failing validation.

This PR reconciles that type drift for the message cluster (IMessage + chat.*). Each leaked field is handled by its true nature rather than one blanket mechanism:

• editedAt / editedBy → added to the base IMessage type. These are persisted on the record and consumed by clients (the "edited" indicator), so they belong on the type. IEditedMessage already narrows them to required, so it is unaffected. This clears the drift for chat.getMessage, chat.update, chat.postMessage, and chat.sendMessage.
• score → modeled via a new IMessageSearchResult type. chat.search attaches a MongoDB $meta: 'textScore' relevance score on $text queries (parseMessageSearchQuery). It is response-only (never persisted) and consumed by the search UI, so it is expressed as IMessageSearchResult extends IMessage { score?: number }, registered with typia and $ref'd from chat.search. Modeling it this way (rather than an inline allOf) means the field survives schema closing — an allOf: [IMessage, { score }] would be rejected by a closed IMessage branch.
• parseUrls → no longer persisted. It is a transient input directive consumed by Message.beforeSave to decide whether to populate message.urls; it was being left on the object and written to MongoDB by sendMessage, so it leaked into every endpoint that reads such a message. It is now deleted before insert, fixing the drift at the source (and improving data hygiene).

Tests:

• A closed-schema regression harness (apps/meteor/server/api/messageResponseDrift.spec.ts) that forces the generated IMessage / IMessageSearchResult schemas closed and asserts realistic wire-format payloads validate with no undeclared fields.
• A chat.postMessage integration assertion that a posted message's response does not echo parseUrls.

Scope note: this PR intentionally covers only the message cluster. The response-envelope drift (success / isClientSafe), the systemic nullable-rendering issue (~196 component types), and the persisted text field on chat.syncMessages are tracked separately under the same issue.

Issue(s)

Closes #42086

Steps to test or reproduce

1. Check out this branch and build core-typings: yarn turbo run build --filter=@rocket.chat/core-typings.
2. Run the schema regression spec (server jest project): it validates edited-message and search-result payloads against closed clones of the generated schemas and expects zero undeclared fields.
3. Run the chat API integration tests (chat.postMessage): posting a message with parseUrls returns 200 and the response message has no parseUrls property.

Before this change, an edited message, a chat.search hit with a score, or a message posted with parseUrls all carry fields absent from their declared response types — accepted only because the generated schemas are open.

Further comments

• Why not allOf for score: an inline allOf: [{ $ref: IMessage }, { properties: { score } }] passes only while IMessage is open. Under a closed IMessage, the referenced branch rejects score (AJV's additionalProperties does not see sibling allOf properties). A dedicated typia-registered superset type generates a single schema that includes score and stays valid when schemas close.
• Why fix parseUrls in sendMessage rather than in the handler: stripping it only in the chat.postMessage response would leave the field in the database, so it would still leak from chat.getMessage, chat.search, etc. Removing it before persist fixes it everywhere.
• Why add editedAt/editedBy to the base type instead of stripping: they are genuine, persisted domain fields the client relies on; stripping would break the edited-message UI.

Summary by CodeRabbit

• Bug Fixes
  • REST message responses now consistently include edit details such as edit time and editor.
  • Chat search results now include relevance scores.
  • The parseUrls input directive is no longer stored or returned in message responses.
• Tests
  • Added coverage to verify response schemas, search results, and parseUrls handling across chat endpoints.