Improve dead key handling in chat on Linux desktop environments

Using German keyboard layout the `^`-key is a dead key, that waits for another keystroke to print special characters (e.g. `^` + `e` = `ê`).

In typical Linux desktop applications this works like this: When `^` is pressed it gets printed with an underline to indicate that the application is waiting for another keystroke. Then you can press Space to just print the `^` or any character that can be combined with `^` to get the special character.

BAR's behavior is currently different. When pressing `^` nothing it printed, but the application also waits for a 2nd valid keystroke. In my opinion this is confusing, especially when hitting Enter, which then doesn't close the chat although it appears empty.

**TLDR** table of how BAR should behave more than other Linux applications

| Environment | Dead key clicked |
|------------------------------------|--------------------------------------------------------------------------|
| Typical Linux desktop applications | Dead key is printed plus underline to indicate waiting for 2nd keystroke |
| BAR | Dead key is not printed and input state is confusing |

Just a screenshot showing where the bug happens and how special characters can be made by using the dead key plus another character:

Maybe also related to #2192

Reproduce the issue in BAR on Linux with a German keyboard layout, focusing on the chat input and the ^ dead key. Compare its behavior with the typical Linux behavior described in the issue, including Space, combinable characters, and Enter when the input appears empty. Done means dead-key input is visibly represented and the chat's input state behaves as expected.

Written by the indexing model from the issue text.