`wp plugin activate a b c` carries on after one of them fails, so an
interrupted run could leave a test helper active while the plugin it stubs
was not. The helper's stub classes then loaded first and every later attempt
died on a redeclaration fatal — a state the retry loop had created and could
not escape. Reproduced on a real environment: all five retries failed
identically and recovery needed `wp plugin deactivate --all` by hand.

Retries now deactivate the configured plugins first, which puts the site back
somewhere activation can succeed from.

Success is also confirmed rather than trusted, since the command can report
success for the set while an individual plugin stayed inactive. Reading that
back needed the command's stdout kept separate from stderr: wp-env writes its
own progress lines to stderr, and the earlier code returned whichever was
non-empty, so the output being parsed was the progress text.