fix: strip carapace double-backslash quoting in compadd capture

[nirvana6]

Problem

Carapace passes pre-quoted words to compadd with -Q, using double backslash escaping (path\\ file instead of path\ file). When fzf-tab's -ftb-compadd captures these words and re-inserts them with -Q, the double backslash is placed literally on the command line. Zsh parses \\ as a literal backslash followed by a word boundary, breaking paths with spaces into separate tokens.

Observed bug: completing a filename with spaces (e.g., 中文 文件.txt) via carapace-accelerated fzf-tab results in 中文\\ 文件.txt on the command line, which zsh treats as two separate words (中文\ + 文件.txt) instead of one.

Root Cause

In -ftb-compadd, the word from compadd arguments is stored as-is. When the original completer (carapace) uses -Q with double-backslash escaping, the stored word contains \\. On re-insertion via _fzf-tab-apply (which preserves -Q), the double backslash is treated as literal characters.

Fix

In -ftb-compadd, after capturing word=$__hits[i], strip one level of backslash quoting when -Q was present in the original compadd call:

(( ${_opts[(I)-Q]} )) && word=${word//\\\\/\\}

This converts \\ → \ (two literal backslashes to one), matching the format zsh expects for pre-quoted compadd -Q words.

Safety

• Only activates when -Q is in the original args — native zsh completions (_files, _path_files) do not use -Q and are unaffected
• Only affects carapace's double-backslash convention — correctly-quoted words (single \) contain no \\ sequence to match
• File names with literal backslashes: if a path genuinely contains \ characters, carapace would escape them as \\\\ (4 backslashes). Stripping \\ → \ converts 4→2, preserving the correct escape level

Fixes #503