QtWebEngine apps crash on startup when host has a custom XKB keymap

Apps built on this BaseApp abort during startup when the user has a custom XKB symbols file on the host, because the bundled Chromium can't see it from inside the sandbox. Reported downstream in flathub/org.zealdocs.Zeal#16, and the same crash shows up for qutebrowser/qutebrowser#7874, FreeCAD/FreeCAD#16680, NixOS/nixpkgs#226484, and others.

Trace:

```
xkbcommon: ERROR: Couldn't find file "symbols/se_code" in include paths
xkbcommon: ERROR: 1 include paths searched:
xkbcommon: ERROR: /usr/share/X11/xkb
FATAL:xkb_keyboard_layout_engine.cc(661)] Keymap file failed to load: se,se_code-nodeadkeys,se_code
```

The cause is in Chromium's [`xkb_keyboard_layout_engine.cc`](https://chromium.googlesource.com/chromium/src/+/refs/heads/main/ui/events/ozone/layout/xkb/xkb_keyboard_layout_engine.cc):

```cpp
xkb_context_.reset(xkb_context_new(XKB_CONTEXT_NO_DEFAULT_INCLUDES));
xkb_context_include_path_append(xkb_context_.get(), "/usr/share/X11/xkb");
```

`NO_DEFAULT_INCLUDES` disables xkbcommon's normal search (so `$XDG_CONFIG_HOME/xkb` is ignored), and `/usr/share/X11/xkb` is hardcoded as the only path — which inside the sandbox is the runtime's, missing any custom host symbols. Flatpak won't let us mount over `/usr`, so downstream apps can't work around this.

A small Chromium patch on the BaseApp that either drops `NO_DEFAULT_INCLUDES` or also appends `$XDG_CONFIG_HOME/xkb` would let users drop their custom layout into `~/.config/xkb/symbols/` and have it just work, fixing every QtWebEngine-on-Flathub app in one place.