--env with a space in the path reports a truncated path that does not exist #1247

Problem

-e/--env/--boot takes "file arg1 arg2", so it splits its value on the first space. That is deliberate and documented. What is not is the message you get when your path contains a space:

$ bashunit --env "my boot.sh" t_test.sh
Error: cannot read the bootstrap file: 'my'.

The file is right there. The reader is told a path they never typed does not exist, with no hint that the value was split or that the split is why. The obvious next move — checking that my boot.sh exists — confirms it does, which makes the message look simply wrong.

Proposal

Keep the split, explain it exactly when it is the cause. When the value contains a space and the whole value is readable, add:

Error: cannot read the bootstrap file: 'my'.
--env splits its value on the first space to pass bootstrap arguments,
so a path containing one cannot be used. Set BASHUNIT_BOOTSTRAP='my boot.sh' instead.

BASHUNIT_BOOTSTRAP is not split, so it takes the path whole — verified before recommending it, since advice that does not work is what #1221 and #1229 were about.

Scope

src/main/test.sh and src/main/bench.sh carry identical copies of the parse and the message, so the reporter belongs in src/main/validate.sh with the other shared parser validation, and both call it.

The explanation must stay quiet where it would be noise: a genuinely missing file with no space keeps the terse message, and --env "boot.sh arg1" — the reason the split exists — must keep working.