Distinguish stale discovery fixtures from Python SDK discovery regressions

[rmcdaniel]

Problem

The published-artifact Python lifecycle probe currently classifies every RuntimeDiscoveryUnavailable raised during query capability discovery as a runner gap. That conflates two materially different outcomes: the harness failing to serve the current discovery contract, and the SDK rejecting a valid 200 discovery response that advertises worker_protocol.server_capabilities.query_tasks=true. The latter is user-visible product behavior and must not be hidden as runner-blocked. The current classification can also report that the artifact cell was not executed after earlier start and signal operations already ran.

Acceptance criteria

• Record whether the expected discovery request was observed and whether the harness returned the valid public status and capability shape.
• Classify a missing, stale, or unserved discovery fixture as runner-gap.
• Classify an SDK refusal after a valid discovery response as product-gap owned by the Python SDK surface, with bounded structured exception and response evidence.
• Preserve completed-operation and artifact-execution evidence instead of marking already-exercised cells unexecuted.
• Add regressions for both an unserved discovery request and an SDK rejection after a valid discovery response.

Delete when

Delete when workflow-lifecycle conformance cannot convert a Python SDK regression following a valid Server discovery response into a runner-blocked result.