PMP diagnostics fail on macOS when the conda env path contains a space (`Application Support`)

Running a PMP ENSO diagnostic end-to-end fails on macOS because the provider's conda environment lives under the default config dir `~/Library/Application Support/climate_ref/software/...`, whose path contains a space. Console-script shebangs inside that env (`#!/Users/.../Library/Application Support/.../bin/python`) can't handle the space and get truncated at it.

Seen with `ref test-cases mint --provider pmp --diagnostic enso_tel` (and `enso_proc`): the ENSO driver launches, runs for a while, then dies with

```
FileNotFoundError: [Errno 2] No such file or directory: '/Users//Library/Application'
```

Note: moving only `REF_RESULTS_ROOT` / `REF_SCRATCH_ROOT` off the space-containing path is **not** enough — the failure comes from the software/conda prefix, not the output directories.

**Environment:** macOS, default `REF_CONFIGURATION = ~/Library/Application Support/climate_ref` (software env under `.../software`).

**Workaround:** set `REF_SOFTWARE_ROOT` to a space-free path and recreate the provider environment there before running.

**Suggested fix:** reject or normalise whitespace in the software root (fail fast with a clear message), or default the software root to a space-free location on macOS.

Start with `ref test-cases mint --provider pmp --diagnostic enso_tel` on macOS using the default `REF_CONFIGURATION` and a space-containing software path; compare it with `REF_SOFTWARE_ROOT` set to a space-free location. Trace how the software/conda prefix is selected, and consider the suggested fail-fast or default-path behavior; done means the diagnostic no longer truncates the shebang path and reports a clear configuration error when appropriate.

Written by the indexing model from the issue text.