web: the PTT reply log shows spaces, not plus signs (V-533)

The transcript beside the spoken reply read "на+04.08.2026+ничего+нет."
X-Reply-Text was written with url.QueryEscape, which is form encoding and
writes a space as "+", and static/app.js reads it with decodeURIComponent,
which only knows "%20". Every space in a spoken reply arrived as a plus.

Fixed on the Go side rather than by replacing plus with space in the client:
the encoding is a property of the header, and a client that has to know which
flavour it got is a client that will get it wrong again. Escaping in the
client's own dialect also keeps a plus the speaker actually said — "2+2" — from
becoming a space.

PathEscape writes %0A for a newline too, so a two-line reply stays a legal
header value instead of a truncated one.

The test round-trips through a stand-in for decodeURIComponent rather than
checking the encoder alone, because QueryEscape passes any assertion that only
looks at what went in.

Cosmetic and log-only. The audio was never affected.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011x5DgnExQ5XZy8TZPs5bot

cmd/mavweb/main.go

@@ -1540,7 +1540,13 @@ func handlePTT(w http.ResponseWriter, r *http.Request, voiceAddr string, session
 			return
 		}
 		w.Header().Set("Content-Type", "audio/l16;rate=16000;channels=1")
-		w.Header().Set("X-Reply-Text", url.QueryEscape(pttResp.ReplyText))
+		// PathEscape, not QueryEscape (Vikunja #533). QueryEscape writes a space
+		// as "+", which is form encoding, and the client decodes this header
+		// with decodeURIComponent, which only knows "%20" — so every space in a
+		// spoken reply reached the on-page log as a plus sign. PathEscape is the
+		// flavour decodeURIComponent actually reverses, which keeps the encoding
+		// a property of the header rather than something the client has to know.
+		w.Header().Set("X-Reply-Text", url.PathEscape(pttResp.ReplyText))
 		w.Write(pttResp.ReplyAudio.Bytes)
 		return
 	}