Message attachment text capped at ~360px width regardless of container size (root cause identified, related to #37111)

Description:

Message attachment text is rendered in a fixed ~360px-wide column regardless of the actual width of the message pane/window. This affects any integration that sends content via the attachments payload field (e.g. incoming webhooks), causing long lines to wrap far more aggressively than the available space allows. This appears to be the same underlying issue as #37111, which was closed for lack of detail. This report adds the missing root-cause information and confirms the bug reproduces with a second, independent integration.

Steps to reproduce:

1. Configure an incoming webhook integration that posts a message using the attachments array with a text field (in this case, the plugin from https://github.com/alphanodes/redmine_messenger, but another poster's #37111 initially reported this with Grafana.
2. Send a message where the attachment text field contains a reasonably long paragraph (a full sentence or more).
3. View the message in a normal channel, in a browser window wide enough that the message pane itself is several hundred pixels wide (e.g. 900px+).

Expected behavior:

Attachment text should wrap to use the full available width of the message pane, the same way a plain top-level message (msg/text field, not attachments) does.

Actual behavior:

Attachment text wraps at a fixed width of approximately 360px, producing short lines (roughly 40 characters per line) even when the surrounding message pane is significantly wider. [Insert your screenshot here.]

Using Firefox DevTools, I traced the cause: the element rendering attachment content (.rcx-message-attachment) inherits max-width: 360px and width: 360px from a separate, auto-generated CSS class (in my build, rcx-css-c2qgoa), not from any width/flex property on the semantic .rcx-message-attachment class itself, which has no width constraint of its own. The underlying max-width: 360px rule it carries appears to be the actual source of the constraint across versions, since #37111 reported the same symptom independently over a year ago.

A local workaround via Admin → Layout → Custom CSS, overriding that specific hashed class with max-width: 100% !important, resolves the display issue — but since hashed class names regenerate on rebuild/upgrade, this isn't a stable fix.

Server Setup Information:

• Version of Rocket.Chat Server: 8.8.0
• License Type: Starter
• Number of Users: ~10
• Operating System: Ubuntu 24.04 LTS
• Deployment Method: docker
• Number of Running Instances: 1
• DB Replicaset Oplog:
• NodeJS Version:
• MongoDB Version:

Client Setup Information

• Desktop App or Browser Version: Firefox 155.0.1
• Operating System: Ubuntu 24.04 LTS

Additional context

Related to #37111 (closed, stat: need more info), which reported the identical symptom via a Grafana webhook integration nearly a year prior, with the same "forced into 360px width" description. This confirms the bug is not specific to one integration and has persisted across at least two independent reports.

Relevant logs:

N/A — this is a pure CSS/rendering issue, not a server-side error; no relevant server or browser console logs were produced.

Start by locating the message attachment renderer and the styles that produce .rcx-message-attachment, then reproduce the issue with an incoming webhook attachment containing a long paragraph. Trace the generated width constraint back to its source rather than the hashed class; done means attachment text uses the available message-pane width without affecting ordinary message rendering.