a bug in the update center that it offers such an update

Known limitation, when we suspend plugins we always need to check whether any dependent plugins exist and suspend them likewise. Some folks have also published uninstallable plugins before (depending on incrementals or similar) – essentially what's happening here, except not involving a suspension.

The problem arose because https://github.com/jenkinsci/workflow-cps-plugin/pull/512 updated that plugin’s baseline to 2.332.x (perhaps for a solid reason, perhaps not), and later https://github.com/jenkinsci/workflow-api-plugin/pull/221 had a soft requirement that https://github.com/jenkinsci/workflow-cps-plugin/pull/534 also be applied. https://github.com/jenkinsci/workflow-durable-task-step-plugin/pull/226 also depends on the workflow-api update, but these two plugins had an older baseline than workflow-cps; and unlike the bom, the update center just automatically offers the latest version of every plugin compatible with a given LTS baseline discovered in Artifactory without an as-code manifest, only permitting manual overrides via artifact-ignores.properties which is applied to all lines.

The root of the problem, arguably, is lack of JENKINS-49651: no way for the workflow-api update to programmatically express that older versions of workflow-cps should be considered incompatible.

Seems like the solution should be to follow up https://github.com/jenkinsci/workflow-api-plugin/pull/226 by requiring 2.332.x in workflow-durable-task-step, then blocking https://github.com/jenkinsci/workflow-durable-task-step-plugin/releases/tag/1144.vd77b_57189936 (from all lines).