Fix best-interpreter lookups when there is an invalid interpreter in the PATH

[zanieb]

Closes #10978

The root cause is the same as #10908 — I should have been more careful with the original change.

[charliermarsh]

What's the nested Result? What do the two levels indicate?

[zanieb]

This was a design decision in Python discovery a while back (which I'm sort of regretting as it was the source of this bug)

The outer error is if we fail during discovery for some reason.
The inner error is we don't find a Python interpreter.

uv/crates/uv-python/src/discovery.rs

Lines 166 to 179 in db4ab9d

	/// The result of an Python installation search.
	///
	/// Returned by [`find_python_installation`].
	type FindPythonResult = Result<PythonInstallation, PythonNotFound>;
	/// The result of failed Python installation discovery.
	///
	/// See [`FindPythonResult`].
	#[derive(Clone, Debug, Error)]
	pub struct PythonNotFound {
	pub request: PythonRequest,
	pub python_preference: PythonPreference,
	pub environment_preference: EnvironmentPreference,
	}

The bug is that I changed things so a deferred discovery failure is sometimes raised instead of the inner error to improve error messages when there's an invalid interpreter on the path. However, this broke some downstream code where we take actions after failing to find an interpreter and counted the function to only return fatal outer errors.

[zanieb]

I was worried about breakage here when I made the change, but foolishly trusted the test coverage (which it seems didn't exist for the case of a broken interpreter)