Non-ASCII characters in q= are not decoded when Assistant is opened via a URL template (umlaut stays as %C3%BC)

Kagi Assistant fails to decode percent-encoded non-ASCII characters passed through the `q` URL parameter, so a query typed as `bügel` is submitted to the model as the literal string `b%C3%BCgel`. The bug, reported against Firefox 154.0.1 on MacOS 26.6.2, reproduces both via a custom browser search engine using the URL `https://kagi.com/assistant?profile=deepseek-v4-1-flash&internet=true&q=%s` and by opening `https://kagi.com/assistant?q=b%C3%BCgel` directly, while spaces are preserved correctly. Expected behavior is that the prompt box and submitted thread show `bügel`.

When Kagi Assistant is invoked through a URL with the q parameter, non-ASCII characters are passed through percent-encoded instead of being decoded. Typing bügel produces the literal text b%C3%BCgel in the submitted prompt: meine brille mit plasikgestell ist am b%C3%BCgel über der Nase glatt gebrochen. Wie repariere ich das Note that spaces are preserved correctly, only the umlaut remains encoded. Steps to reproduce 1. Add a browser search engine in Firefox with the URL: https://kagi.com/assistant?profile=deepseek-v4-1-flash&internet=true&q=%s 1. Use that search engine with a query containing a non-ASCII character, e.g. bügel . 2. The Assistant opens with b%C3%BCgel as literal text in the prompt. Also reproducible by opening the encoded URL directly: https://kagi.com/assistant?q=b%C3%BCgel Expected behaviour The prompt box / submitted thread shows bügel . Actual behaviour b%C3%BCgel is submitted verbatim, both to the model and as far as I can tell in the visible prompt. Environment - Firefox 154.0.1 on MacOS 26.6.2