xtermjs: enable the Kitty keyboard protocol once the vendored bundle reaches 6.1.0

## Context

`XtermJsEmu` is currently the only backend that reports no Kitty keyboard flags. It declares this in its conformance opt-in:

```rust
// crates/tui-test/src/terminal/xtermjs.rs
crate::emulator_conformance_tests!(
|cols, rows, profile| { ... },
crate::terminal::conformance::Divergences {
underline_color_needs_a_style: true,
no_kitty_keyboard: true,
}
);
```

That divergence is a version limit, not a design one.

## What changed upstream

xterm.js added the protocol behind a new `vtExtensions` terminal option:

```ts
export interface IVtExtensions {
/**
* Whether the [kitty keyboard protocol][0] (`CSI =|?|>|< u`) is enabled.
* ... The default is false.
*/
kittyKeyboard?: boolean;
kittySgrBoldFaintControl?: boolean;
win32InputMode?: boolean;
colorSchemeQuery?: boolean;
}
```

()

We are pinned to `@xterm/headless` **6.0.0** (`crates/tui-test/assets/xtermjs/pinned.json`), which has no `vtExtensions` at all. Verified against both bundles:

| symbol | 6.0.0 (vendored) | 6.1.0-beta.302 |
| --- | --- | --- |
| `vtExtensions` | absent | present |
| `kittyKeyboard` | absent | present |
| `win32InputMode` | absent | present |
| `colorSchemeQuery` | absent | present |

`vtExtensions` first appears in the 6.1.0 beta line. `npm dist-tags` still lists `latest` as 6.0.0, and `.github/scripts/vendor-xtermjs.sh --latest` follows `latest`, so this lands on its own once 6.1.0 ships.

## What to do when the bundle reaches 6.1.0

1. Re-vendor: `./.github/scripts/vendor-xtermjs.sh --latest`.
2. In `crates/tui-test/assets/xtermjs/shim.js`, pass the option through in `__boot`, driven by the profile rather than hardcoded:
```js
vtExtensions: { kittyKeyboard: },
```
It defaults to `false` upstream, so it must be set explicitly. This is xterm.js's **native** switch, which makes it the same shape of gating alacritty already gets from `Config::kitty_keyboard` — no read-side filtering needed.
3. Implement `Emulator::keyboard_mode` on `XtermJsEmu`, mapping the modes xterm.js tracks onto `KeyboardMode`'s five flags.
4. Drop `no_kitty_keyboard: true` from the `Divergences` in `crates/tui-test/src/terminal/xtermjs.rs`. The existing conformance cases `conformance_kitty_keyboard_modes_are_pushed_and_popped` and `conformance_kitty_keyboard_can_be_turned_off` then run against xterm.js and should pass with no new test code.

## Also worth a look at the same time

The bump brings three more extensions that are all off or on by default in ways that may shift conformance: `kittySgrBoldFaintControl` (SGR 221/222, defaults **true**), `win32InputMode` (defaults false), and `colorSchemeQuery` (`CSI ? 996 n` / `DECSET 2031`, defaults **true**). The two that default to true are the ones to re-check against the other backends.

Start by checking the pinned version in crates/tui-test/assets/xtermjs/pinned.json and run ./.github/scripts/vendor-xtermjs.sh --latest when 6.1.0 is available. Update crates/tui-test/assets/xtermjs/shim.js, implement Emulator::keyboard_mode, and remove the divergence in crates/tui-test/src/terminal/xtermjs.rs. Done means the existing Kitty keyboard conformance cases pass for xterm.js without new test code.

Written by the indexing model from the issue text.