fix(ci): match the FLASH_ATTN pin as a fixed string, not a BRE

[phantomic12]

What is broken

The prio[0] pin in the build-test-vulkan case-gate step is unsatisfiable.
It landed in 16086ae1f (#3375) under a bare grep -q, so grep parsed it as a
BASIC REGULAR EXPRESSION in which [0] is a character class for the digit 0.
The pattern asks for prio0 and can never match the literal prio[0] that
doctest prints under -s. The pin could not succeed from the moment it landed.

#3375 correctly retired two stale pins. It replaced one of them with a third
failure mode: not stale wording, but a pattern that no output can satisfy.

Evidence — the suite passed and the GREP could not

Run 37160385766
on main @ 33fb82b09 fails build-test-vulkan at The Vulkan suite MEASURED a
device rather than skipping past one, and its log separates cause from symptom:

./tests/vt/test_vulkan_backend.cpp:538: SUCCESS: CHECK_FALSE( p.get_device_capability().present() ) is correct!
./tests/vt/test_vulkan_backend.cpp:557: SUCCESS: CHECK( prio[0] == "FLASH_ATTN" ) is correct!
[doctest] test cases:  1 |  1 passed | 0 failed | 45 skipped
[doctest] assertions: 13 | 13 passed | 0 failed |
[doctest] Status: SUCCESS!
##[error]Process completed with exit code 1.

Every assertion passed, the summary is green, the Vulkan device was genuinely
measured — and the step still exits 1, because the gate cannot be satisfied. The
lane has been red on main since 2026-10-02 while proving something true.

Replaying that run's captured vulkan-platform-case.log through the three pins:

pin	before	after
CHECK_FALSE( p.get_device_capability().present() ) is correct	exit 0	exit 0
CHECK( prio[0] == "FLASH_ATTN" ) is correct	exit 1	exit 0
test cases: *1 | *1 passed	exit 0	exit 0

The fix

-qF, so grep compares literal text. No other pin moves.

This is the only unsatisfiable pin in the file: git grep over .github finds
the remaining bracketed pins at 1908-1910 and 1944-1945, and those are -qE
using [[:space:]], [1-9] and [0-9] as intended character classes.

Negative control

A fixed-string pin that matches everything is worthless, so: a deliberately wrong
CHECK( prio[1] == "FLASH_ATTN" ) is correct! is still rejected (exit 1).
The pin keeps its teeth.

Honest gaps

• Replayed against a captured runner log, not a fresh Vulkan device on this
  machine; there is no GPU and no toolchain here, so no build was run. The log is
  the real output of the run cited above.
• python3 scripts/check-commit-style.py and
  python3 scripts/check-commit-trailers.py over upstream/main..HEAD: pass.
  .github/workflows/ci.yml re-parses with PyYAML (19 jobs).
• No speed claim. No GPU, checkpoint, oracle or performance run occurred.
• The step name promises the suite measured a device. It does — but a pin that
  cannot fail for the right reason cannot show that. This PR restores the
  ability to ask the question; the surrounding Windows and CPU lanes are red on
  main independently of it and are untouched here.

Update (2026-10-04): rebased onto e67a071a6; main reached the same line independently

The PR went CONFLICTING when main advanced past 33fb82b09. It is now
rebased (head 6a5e27ba9), clean, and its two gates re-run at rc=0 over
upstream/main..HEAD.

One fact a reviewer should have: main already fixed this same defect in
ded529eef ("ci: escape the prio bracket in the vulkan platform-case grep"),
after run 37202846607
hit the identical signature on PR #3393's head — green suite, then exit 1 at
the platform-case step — as its commit message records. The two fixes are
behaviorally equivalent; this PR keeps the -qF form because a fixed string
has no escaping to rot the next time the pin's text is edited, and it carries
the failure-mode comment quoted above in place of the three-line escape note.
Sections What is broken and Evidence describe main @ 33fb82b09 as of
filing and are left unchanged; main's e67a071a6 CI run was still queued at
the time of this update.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:buffy/space-bunny-alpha [freebuff]