test(compat): make the space-in-path premise able to fail (main is over its assertion baseline)

[fujibee]

Declared reviewers: 1

Change class: CI only. No product code, no shipped behaviour.

main is red, and this is why

check-enforced-assertions reports 639 against a baseline of 638, on main
itself — so every branch taken from it inherits the failure, in three checks
(the standalone job and the bats cases on ubuntu and macos).

Located by comparing the checker's own enumeration at the commit that set the
baseline against origin/main, per file rather than per line — the line
numbers move everywhere and a line diff cannot separate "moved" from "added":

ba773a6 (baseline set, 638)  vs  origin/main (639)
  +1  tests/test_compat_posix.bats     (0 -> 1)
  everything else unchanged

The one entry:

tests/test_compat_posix.bats:112: [[ "$raw" == *"Application Support"* ]]

The fix

A non-last [[ ]] cannot fail a bats test on bash 3.2 (#670), so as written
this premise check asserted nothing. It is a premise worth keeping — the case
below it only means something if ps really did report a path with a space —
so it becomes a plain command rather than being deleted.

Measured

before:  check-enforced-assertions: 639 ... baseline is 638      (red)
after:   check-enforced-assertions: 638 ... at the baseline (638)
tests/test_compat_posix.bats                                      5/5

And that the line can now do its job, which the old form could not:

premise pointed at a string ps never reports  ->  case 5 RED
the same substitution under the old `[[ ]]`   ->  green

The baseline number is left at 638 rather than raised: the tree meets it again.

[fujibee]

Closing in favour of #887, which was open first and is already cleared by two reviewers on the same head.

#887 is also the better fix, for a reason worth writing down rather than just deferring to: it prints what ps actually returned before it fails. This premise exists because ps differs between environments, so the value that broke it is the one thing the next reader needs — and my version would have failed with the string it wanted and not the string it got.

The measurements here still stand and are not specific to either fix:

• the extra entry was tests/test_compat_posix.bats:112, found by diffing the checker's enumeration per file rather than per line (line numbers move everywhere, so a line diff cannot separate "moved" from "added")
• a non-last [[ ]] cannot fail a bats test on bash 3.2 (On macOS, only the last assertion in a bats test is enforced (bash 3.2 errexit) #670), so as written the premise asserted nothing — pointing it at a string ps never reports left the case green