test: fix locale-dependent failure in "don't expand file name"

[alberti42]

Fix locale-dependent test failure in "don't expand file name"

Summary

This PR adds a single line — export LC_ALL=C — to the test suite
(test/fzftab.ztst) to enforce deterministic sort order. Without it, the
"don't expand file name" test fails on machines running a non-C locale (e.g.
en_US.UTF-8) because locale-aware collation sorts filenames differently than
ASCII order. No production code is touched.

TL;DR — detailed explanation

The test case "don't expand file name" (line 206 of test/fzftab.ztst) verifies
that fzf-tab does not execute shell metacharacters embedded in filenames. It
creates a file named

direcho yes > called

pre-sets a sentinel file called to no, triggers completion, and then asserts
called:no — proving the backtick expression was never evaluated as a command
substitution.

The test fails on non-C locales for an unrelated reason: the expected completion
order is:

>C1:{dir1/}
>C1:{dir2/}
>C1:{dir`echo yes > called`}

All three names share the prefix dir, so the tiebreaker is the fourth
character: 1, 2, or a backtick. Under C locale, backtick (\x60, ASCII 96)
sorts after digits, so the backtick filename comes last. Under en_US.UTF-8
(and most Unicode-aware locales), backtick sorts before alphanumeric
characters, putting dir\...`` first and breaking the expected order.

This is a purely accidental failure — the test is not about sort order — but it
causes the whole test case to be reported as failed on any developer machine not
running a C locale.

History

• PR Fix: sorts completion candidates to present a stable, predictable list #557 worked around this by adding LC_ALL=C to production code
  (lib/-ftb-generate-complist), forcing C-locale sort order for all users.
• PR Revert "Fix: sorts completion candidates to present a stable, predictable list" #566 correctly reverted that change: fzf-tab should respect the user's
  locale, not override it.
• The root cause — the test expectation assuming C-locale collation — was never
  fixed.

Fix

Add export LC_ALL=C to the %prep section of the test file, immediately after
unset -m LC_\* which already clears all locale variables:

%prep
  unset -m LC_\*
  export LC_ALL=C   # ← this line
  ZSH_TEST_LANG=
  ...

This sets C locale for the test shell and is inherited by the zpty subprocess
started later by comptestinit, ensuring deterministic ASCII collation for all
test cases regardless of the developer's system locale.

No production code is touched.

No interference with other tests

All expected outputs in the test file use ASCII characters. C-locale collation
for ASCII strings is identical to any Unicode-aware locale, so no other test is
affected by this change.

The ZSH_TEST_LANG mechanism (lines 6–14) is unaffected. That code searches for
a UTF-8 aware locale by testing [[ é = ? ]] — in zsh, ? is a glob pattern
matching exactly one character, so this expression is only true when the locale
correctly treats the two-byte UTF-8 sequence é as a single character. The
found locale is stored in ZSH_TEST_LANG and used exclusively for
character-width assertions elsewhere in the test file. It has nothing to do with
sort order.