tests/pyvcp: filter the halcmd "Waiting for component" pacifier from result

[grandixximo]

Fixes #4287.

Problem

The pyvcp test flakes on slow or busy CI:

+Waiting for component 'mypanel' to become ready....
 mypanel float OUT 0 mypanel.dial-a-out
 ...

The "Waiting for component..." pacifier is printed by halcmd's loadusr -Wn to stderr after 2 s of waiting. It lands in the test's result file anyway because Ubuntu 24.04's xvfb-run executes the wrapped command with "$@" 2>&1, merging stderr into stdout (Debian's and upstream xorg's xvfb-run keep the streams separate). On a loaded ubuntu CI runner, pyvcp takes >2 s to become ready, the pacifier fires, and the merged line survives the sed '/mypanel/!d' filter because it contains the component name, breaking the compare against expected.

I reproduced this byte-identically on a Debian host by extracting Ubuntu noble's xvfb-run (xvfb_21.1.12-1ubuntu1.8_amd64.deb), delaying pyvcp startup with a sleep wrapper, and saturating the CPU.

Fix

Drop the pacifier line in the sed expression that already sanitizes result, as suggested by @BsAtHome.

Testing

• Ubuntu xvfb-run + delayed pyvcp + saturated CPU: was XFAIL with the exact CI diff, now passes, result identical to expected.
• Normal test run passes.

[BsAtHome]

I'm not sure this is the right place to "fix" this. Changing the output based on redirection may have some unexpected problems.

It may be better to kill the line in the test. There already is a sed line to remove everything that is not 'mypanel'. Why not simply add a sed line to remove the line Waiting for component?

[grandixximo]

You're right, the test is the better place. The pacifier on stderr is a useful diagnostic in batch logs, and pyvcp turned out to be the only test that both runs halcmd under xvfb-run and exact-compares captured output. Reworked the PR to filter the line in test.sh; verified with the same repro (Ubuntu's xvfb-run, delayed component startup) that the compare now passes.