Bedrock client (protocol 1001 / MC 26.x) disconnects on join when a long boss bar title is sent

## Describe the bug A Bedrock client on the newest protocol (**1001**, MC Bedrock 26.x) is immediately disconnected (RakNet `CLOSED` → "Bedrock client disconnected" / `geyser.network.disconnect.closed_by_remote_peer`) about 1–2 seconds after joining, with **no server-side error**. The client itself closes the connection while parsing a packet Geyser sent. After logging every outbound packet, the cause is a **`BossEventPacket` with a very long, formatting-heavy title** produced by the [TabTPS](https://github.com/jpenilla/TabTPS) plugin's boss bar. Geyser forwards the title verbatim; the new client rejects it and disconnects. Older Bedrock clients tolerate the same title. This is **not** boss bars in general — short, plain boss bars (e.g. from an auth plugin) work fine on the same client. Only the long/format-dense one crashes. ## Steps to reproduce 1. Backend (Paper) with the TabTPS plugin, boss bar enabled (modules `tps,mspt,ping`). 2. Connect with a Bedrock client on **protocol 1001 (MC 26.x)** via Geyser. 3. The boss bar `CREATE` packet is sent → client disconnects within ~1s. 4. A/B confirmed: TabTPS boss bar **enabled → always disconnects**; **disabled → joins fine**. ## Evidence (captured outbound packet) The offending packet, logged just before the disconnect (section signs shown as `&`, `(len=...)` is the character count of the title string): ``` BossEventPacket {action=CREATE, bossId=4, health=0.0100, color=3, overlay=1, title=(len=293) '&r&7xyz.jpenilla.tabtps.common.messages/label.tps&r&f:&r &r&a2&r&a0&r&a,&r&20&r&20&r &r&7xyz.jpenilla.tabtps.common.messages/label.mspt&r&f:&r &r&a0&r&a,&r&a5&r&20&r &r&7xyz.jpenilla.tabtps.common.messages/label.ping&r&f:&r &r&a0&r&fxyz.jpenilla.tabtps.common.messages/label.milliseconds_short'} ``` Two notable things about this title: - It is **293 characters**, packed with per-character reset/colour codes. - It contains **unresolved Adventure translation keys** (`xyz.jpenilla.tabtps.common.messages/label.tps`, containing a `/`). A subsequent `UPDATE_NAME` for the same boss bar has them resolved and is shorter (len=109: `&r&7TPS&r&f:&r ... &r&7MSPT ... &r&7Пинг ...`). Disconnect line that follows: ``` ... disconnected from the Java server because of Bedrock client disconnected ``` ## Expected behaviour Geyser should sanitise / length-cap boss bar titles (and ideally other text fields) to what the Bedrock client accepts, rather than forwarding content that makes the newest client drop the connection. A title that is merely too long or oddly formatted should degrade gracefully, not disconnect the player. ## Environment - Geyser: 2.10.1-SNAPSHOT (git-master-`232f873`), BungeeCord/Waterfall platform. - Bedrock client: MC 26.x, **protocol 1001** (default supported protocol of this build). - Java server: Paper, MC 1.21.x. Plugin sending the boss bar: TabTPS. ## Length vs content — confirmed it is LENGTH Reducing the TabTPS boss bar to a single module shortens the title and **fixes the disconnect**: | Title | Length | Result | |-------|--------|--------| | `&r&7TPS&r&f:&r &r&a2&r&a0&r&a,&r&20&r&20` (1 module) | **40** | joins fine, boss bar updates normally | | the `CREATE` title above (3 modules, unresolved keys) | **293** | **disconnects on join** | So the trigger is the **title length / number of formatting runs**, not specific characters, and not update frequency (the short boss bar spams `UPDATE_PERCENTAGE`/`UPDATE_NAME` every tick without issue). The breaking threshold is somewhere between 40 and 293 characters on protocol 1001. ## Additional notes - Suggested fix: cap/sanitise the boss bar title length in `BossBar` before sending, so an over-long title is truncated instead of disconnecting the client. - Likely also worth reporting to TabTPS that it emits **unresolved Adventure translation keys** (`xyz.jpenilla.tabtps.common.messages/label.tps`) in the first `CREATE` packet, which inflates the title.