qtbase: fix crash in QString::at on malformed unicode

[overdeadsss]

Problem:
The current implementation of QString::at(int i) and QString::operator[](int i) in qtbase relies on Q_ASSERT for bounds checking. In release builds, these asserts are often compiled out or lead to undefined behavior/crashes when the text layout engine (e.g., during HarfBuzz shaping or complex text rendering) attempts to access an index outside the string's actual bounds.

This is particularly reproducible when the application processes specific complex Unicode sequences, such as extremely long Arabic ligatures or malformed RTL/LTR sequences, which can confuse the layout engine's index calculations.

Example of "Unicode bombs" causing the crash:
The crash can be triggered by sending or viewing a music-message containing many repeated complex ligatures in title or description, for example:

U+FDFD (Arabic Ligature Bismillah Ar-Rahman Ar-Rahim): ﷽

Combinations of ZWJ (Zero Width Joiner) and multiple skin tone modifiers.

Long sequences of combining marks.

A string like ﷽﷽﷽... (repeated multiple times) often leads to out-of-bounds access during the shaping phase.

Solution:
This patch introduces explicit bounds checking using uint(i) comparison. By casting the index to unsigned int, we simultaneously check if the index is negative or greater than/equal to the string size.
If the index is out of bounds, the function now returns a default-constructed QChar() instead of triggering a fatal crash.

Testing:

Built tdesktop with this patched version of qtbase.

Sent the "Bismillah" (U+FDFD) sequence mentioned above.

Result: The application remains stable, the text may not render perfectly, but the process does not terminate.

[CLAassistant]

All committers have signed the CLA.

[ilya-fedin]

Looks like you're fixing the problem at the wrong level? It's an API contract that one must not pass out-of-bounds index.