Install error message getting propagated to most conditions

[perdasilva]

In cases where the extension cannot be installed, the error message is getting added to most conditions. We should probably not propagate the error message to the deprecation conditions. For example:

{
    "lastTransitionTime": "2025-06-03T07:51:05Z",
    "message": "validating bundle \"devspacesoperator.v3.21.0\": bundle \"devspacesoperator.v3.21.0\" has a dependency declared via property \"olm.package.required\" which is currently not supported",
    "observedGeneration": 1,
    "reason": "Retrying",
    "status": "True",
    "type": "Progressing"
},
{
    "lastTransitionTime": "2025-06-03T07:51:05Z",
    "message": "No bundle installed",
    "observedGeneration": 1,
    "reason": "Failed",
    "status": "False",
    "type": "Installed"
},
{
    "lastTransitionTime": "2025-06-03T07:51:05Z",
    "message": "validating bundle \"devspacesoperator.v3.21.0\": bundle \"devspacesoperator.v3.21.0\" has a dependency declared via property \"olm.package.required\" which is currently not supported",
    "observedGeneration": 1,
    "reason": "Failed",
    "status": "False",
    "type": "Deprecated"
},
{
    "lastTransitionTime": "2025-06-03T07:51:05Z",
    "message": "validating bundle \"devspacesoperator.v3.21.0\": bundle \"devspacesoperator.v3.21.0\" has a dependency declared via property \"olm.package.required\" which is currently not supported",
    "observedGeneration": 1,
    "reason": "Failed",
    "status": "False",
    "type": "PackageDeprecated"
},
{
    "lastTransitionTime": "2025-06-03T07:51:05Z",
    "message": "validating bundle \"devspacesoperator.v3.21.0\": bundle \"devspacesoperator.v3.21.0\" has a dependency declared via property \"olm.package.required\" which is currently not supported",
    "observedGeneration": 1,
    "reason": "Failed",
    "status": "False",
    "type": "ChannelDeprecated"
},
{
    "lastTransitionTime": "2025-06-03T07:51:05Z",
    "message": "validating bundle \"devspacesoperator.v3.21.0\": bundle \"devspacesoperator.v3.21.0\" has a dependency declared via property \"olm.package.required\" which is currently not supported",
    "observedGeneration": 1,
    "reason": "Failed",
    "status": "False",
    "type": "BundleDeprecated"
}

[joelanford]

Yeah this clearly looks off! If a bundle resolves correctly, but then fails to install, we should:

• populate package and channel deprecations correctly
• set bundle deprecation to unknown because no bundle is installed.

The bundle deprecation should be in reference to the installed bundle not the resolved bundle.

What if resolution fails though? Lots of potential variants to think through there.

• if package doesn't exist?
• if package exists but none of a user's specified channels exist?
• if package/channels exist, but there's nothing in the version range?

iirc, our current resolver functionality makes dealing with these variations non-trivial.

[joelanford]

I found this comment I left in our code:

	// set deprecation status after _successful_ resolution
	// TODO:
	//  1. It seems like deprecation status should reflect the currently installed bundle, not the resolved
	//     bundle. So perhaps we should set package and channel deprecations directly after resolution, but
	//     defer setting the bundle deprecation until we successfully install the bundle.
	//  2. If resolution fails because it can't find a bundle, that doesn't mean we wouldn't be able to find
	//     a deprecation for the ClusterExtension's spec.packageName. Perhaps we should check for a non-nil
	//     resolvedDeprecation even if resolution returns an error. If present, we can still update some of
	//     our deprecation status.
	//       - Open question though: what if different catalogs have different opinions of what's deprecated.
	//         If we can't resolve a bundle, how do we know which catalog to trust for deprecation information?
	//         Perhaps if the package shows up in multiple catalogs and deprecations don't match, we can set
	//         the deprecation status to unknown? Or perhaps we somehow combine the deprecation information from
	//         all catalogs?
	SetDeprecationStatus(ext, resolvedBundle.Name, resolvedDeprecation)