X11: NUL-producing keys (e.g. Ctrl-Space) log spurious `Received malformed char` warnings

Description

On the X11 backend, pressing a key that resolves to NUL (e.g. Ctrl-Space) logs a spurious worker warning per key press/release:

[worker(...)] [WARN] Received malformed char: data provided contains an interior nul byte at byte position 0

The warning suggests corrupt detector output, but the input is a legitimate key event and detection continues correctly (value falls back to None). Root-cause chain, all verified against upstream master this session:

• espanso-detect/src/x11/native.cpp:387-395: event is zero-initialized (InputEvent event = {};), XLookupString writes at most sizeof(buffer)-1 (23) bytes, and buffer_len = res only when res > 0 (otherwise the buffer is memzeroed and buffer_len = 0).
• espanso-detect/src/x11/mod.rs:285-302: the Rust side slices &raw.buffer[..buffer_len+1]. Because res <= 23, byte index buffer_len is always the zero-fill, so the terminal NUL is structurally guaranteed.
• CStr::from_bytes_with_nul fails in exactly two ways (NotNulTerminated, InteriorNul — std docs). The first is unreachable here, so this warn! fires only when X11 itself returned a NUL byte, i.e. normal input.
• The XLookupString contract (man xlookupstring): with the Control modifier on, the KeySym is mapped "to an ASCII control character, and that character is stored in the buffer", returning the stored count. Ctrl-Space therefore yields byte 0x00 with res = 1 — a well-formed event that takes the warn path.
• Corroboration: #1633's reporter used search_shortcut: CTRL + SPACE and their log shows the same paired warnings; #1458 (still open) shows the identical paired signature (older rustc printed it as byte pos 0).

The adjacent to_str failure arm in the same function (char conversion error, mod.rs:294) covers genuinely malformed data (non-UTF-8 bytes, e.g. Latin-1 locale output) and should stay at warn!.

Suggested fix: downgrade only the from_bytes_with_nul Err arm to trace! (NUL key resolves to value: None, same as the existing buffer_len == 0 path for non-text keys). One line.

Steps to reproduce

1. X11 backend (using X11Source), espanso 2.4.x.
2. Press Ctrl-Space (or any key resolving to NUL).
3. Observe two WARN lines per tap (press + release) in espanso log.

Confirmed empirically on espanso 2.4.1 / X11: a single Ctrl-Space tap timestamp-bracketed by two date calls (Thu 10 Sep 2026 13:34:39 +07 / 13:34:41 +07) produced exactly two WARN lines at 13:34:40, nothing else in the surrounding window:

Sep 10 13:34:40 espanso[25976]: 13:34:40 [worker(25976)] [WARN] Received malformed char: data provided contains an interior nul byte at byte position 0
Sep 10 13:34:40 espanso[25976]: 13:34:40 [worker(25976)] [WARN] Received malformed char: data provided contains an interior nul byte at byte position 0

No commit touches this warn line (commit search for "malformed char" returns nothing), so it is unaddressed.

Expected behavior

No warning for well-formed detector output: a NUL key should resolve to value: None silently (trace-level at most), like any other non-text key. warn! should be reserved for genuinely corrupt buffers (the UTF-8 arm).

Screenshots

No screenshot captured.

Logs

Production journal (espanso 2.4.1, X11), paired press/release warnings across a full day:

Sep 07 10:34:17 [worker(3112658)] [WARN] Received malformed char: data provided contains an interior nul byte at byte position 0
Sep 07 10:34:17 [worker(3112658)] [WARN] Received malformed char: data provided contains an interior nul byte at byte position 0
Sep 07 11:18:41 [worker(3112658)] [WARN] Received malformed char: data provided contains an interior nul byte at byte position 0
Sep 07 11:18:41 [worker(3112658)] [WARN] Received malformed char: data provided contains an interior nul byte at byte position 0
Sep 07 14:32:28 [worker(3112658)] [WARN] Received malformed char: data provided contains an interior nul byte at byte position 0
Sep 07 14:32:28 [worker(3112658)] [WARN] Received malformed char: data provided contains an interior nul byte at byte position 0

Identical signature in #1458 (open) and #1633 (closed).

Your environment

• Public source code: https://github.com/espanso/espanso
• Environment name and version (e.g., Rust 1.59.0): N/A (observed in released builds, not built locally)
• Operating system and version (e.g., Ubuntu 20.04.2 LTS): Manjaro v26.1.1, kernel 6.18.45-1-MANJARO (also Kali 6.0.0-kali3 in #1458, Kubuntu 23.04 in #1633)
• Espanso version (e.g., 2.1.4-beta): 2.4.1 (also 2.1.5-beta in #1458, 2.1.8 in #1633)

Self-service

• I'd be willing to fix this bug myself.