fix(instrumentation-py): repair Cursor SDK, Dify, and DSPy OTel 2.x spans

[Nightingalelyy]

Summary

• emit connected failed Cursor agent roots on cancellation and retain state when terminal export fails
• map only provider-exposed Dify models, including terminal streaming usage, without inventing model or cost aliases
• lock DSPy agent/module spans to the common-only contract
• add one patch release intent for all three instrumentations

Validation

• Cursor SDK: 6 passed

• Dify: 8 passed

• DSPy: 16 passed, 1 opt-in live test skipped

• clean wheels built for all three packages

• release inventory and release-intent validation passed

• corresponding examples: 15/15 completed under otel2-fix-py-group-12-20260816T142858Z

• Respan MCP: 15/15 trace trees and 77/77 full records inspected; counts and parent links match, no duplicates/orphans/blank critical content

• expected Cursor cancellation is the only failed record (499)

• Contribution re-audit against every current document under contribution/ passed after f9c9a0e: every DSPy LLM surface now uses canonical llm.request.type=chat, including text-completion models.

• Fresh correction validation: Cursor SDK 6 passed, Dify 8 passed, DSPy 16 passed / 1 skipped; DSPy wheel, release inventory/intents, formatting/import, and diff checks passed; marker otel2-pr-contract-corrections-20260818T133300Z produced 1 connected DSPy trace / 5 full records, all inspected.

External follow-ups

• Dify completion still projects as chat and operation-specific entity names still render as generic task/workflow nodes. The emitted attributes follow the contribution contract, so those remain backend presentation issues.

Companion examples

• fix(examples-py): validate Cursor SDK, Dify, and DSPy OTel 2.x spans respan-example-projects#59

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.