content: Render large emoji in emoji-only paragraphs

[sarafarajnasardi]

content: Render large emoji in emoji-only paragraphs

Summary

This PR updates the message rendering to display paragraphs containing only emojis (Unicode or custom image emojis) at a larger size. This brings the mobile app's presentation into parity with the web app.

To support this, MessageImageEmoji has been updated to derive its size from the ambient text style rather than a fixed pixel value, ensuring custom emojis scale proportionally with the font size.

Screenshots

Before	After

Changes

• Detection: Added logic to identify paragraphs that consist solely of emojis and whitespace.
• Styling: Applied a 2× font scaling to DefaultTextStyle for these paragraphs.
• Components: Refactored MessageImageEmoji to respect the ambient fontSize, enabling it to grow when the parent paragraph's font size increases.

References

• Web Implementation: zulip/zulip#36681
• Design Discussion: #design > emoji-only message presentation
• Feature Request: feature request: Render emoji at larger size when it is the only content of a message. zulip#15390

Fixed Issues

Fixes: #1995

[chrisbobbe]

Hi, welcome! This PR will need test coverage for the feature before we can review it.

[sarafarajnasardi]

Thanks! I'll work on adding the test coverage and will push an update shortly.

[sarafarajnasardi]

I have added the tests coverage

[chrisbobbe]

This implementation doesn't exactly match the issue description: see part (a) in the first sentence of #1995:

When a message consists only of (a) one paragraph which (b) consists entirely of one or more emoji, we plan to start showing the emoji at a larger size.

We don't want the resizing to happen if there are multiple paragraphs in the message, even if point (b) applies to some of them.

[sarafarajnasardi]

I missed the single-paragraph rule. I'll update the logic to check if it's the only paragraph before resizing and add a test case.

[sarafarajnasardi]

I tracked the issue down to invisible LineBreakNode elements inflating the content count.
I added a filter to ignore them, so the logic now correctly identifies when an emoji paragraph is truly the sole content. I also added a regression test to ensure mixed content stays standard size.
Here is the fixed behavior:

[gnprice]

This implementation has several problems. Among them:

• It adds complexity at widget build time for message content. These calculations should instead be done at parse time, so that they're only done once as the user scrolls back and forth or as the widgets rebuild for any other reason.
• It still has the wrong behavior (even after the changes discussed above), because a BlockContentList may be just part of a message and not an entire message.

In general, I think this issue isn't one that a new contributor is likely to be successful at. That's the reason it doesn't have the "help wanted" label. So rather than further spend time reviewing this PR, I'm going to close it; @sarafarajnasardi you're welcome to find a different issue to try contributing on. See #1995 (comment) .