Fix optional extensions with inaccessible PATH entries

[tianrking]

Fixes #3170.

Problem

A missing optional renderer or preprocessor can still fail a build when the
platform reports command lookup differently from ErrorKind::NotFound, or when
the child exits before mdBook writes its JSON input. This regressed the expected
optional = true behavior on Linux.

Change

• Preflight optional extension commands on both Unix and Windows before spawning
  them, so the optional-command decision is not dependent on child-process timing.
• Preserve the child command's working directory when resolving relative command
  paths and relative PATH entries.
• On Unix, treat an inaccessible PATH entry with no usable command as absent,
  while direct command paths and existing/non-executable files still go through
  spawn so their real errors are retained.
• On Windows, mirror std::process::Command's documented bare-command search:
  the executable directory, system directory, Windows directory, then PATH;
  an omitted .exe extension is also considered.
• Apply the common preflight to renderer execution and both preprocessor paths
  (run and supports).

Regression coverage

• Renderer and preprocessor: a missing optional command with an inaccessible
  PATH entry is skipped on Unix.
• Unix: an existing non-executable direct command is not misclassified as
  missing.
• Windows: an extensionless command with an existing .exe is not
  misclassified as missing.

Validation

Local Windows validation with Rust 1.88.0:

• cargo test --workspace --locked
• cargo test --workspace --no-default-features --locked
• cargo test -p mdbook-driver
• cargo test --test testsuite missing_optional -- --nocapture
• cargo clippy -p mdbook-driver --all-targets --no-deps -- -D warnings
• cargo clippy -p mdbook-driver --all-targets --no-default-features --no-deps -- -D warnings
• cargo fmt --all -- --check
• git diff --check

[GuillaumeGomez]

Would be better to handle unix and windows the same.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[tianrking]

@GuillaumeGomez I updated this in 915ae72 to use the same optional-command preflight on Unix and Windows.

• Windows now follows std::process::Command's documented bare-command search locations and .exe elision.
• Direct paths and existing/non-executable files still go through spawn, so their real errors are preserved.
• The Unix inaccessible-PATH renderer and preprocessor regressions remain covered; I also added Unix direct-command and Windows extensionless-command coverage.

The branch has been rebased onto current main. Both fresh CI runs for 915ae72 are green (38 successful checks total). Could you please take another look?

[GuillaumeGomez]

I don't think this is the right approach. Why not fixing the existing error in spawn and crate::handle_command_error instead?

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.