Align task response types with MCP spec

[DaleSeo]

Closes #637, Closes #640

Motivation and Context

The task response types don't match the MCP 2025-11-25 spec. The tasks/get response nested the task under a task key instead of flattening it. The tasks/result response used fields that aren't in the spec, rather than passing through the original request's result. The tasks/cancel handler didn't return anything instead of the final task state. Also, the Task struct had last_updated_at as optional and omitted ttl when it was null, but both should always be included. This PR fixes these response types and updates the #[task_handler] proc macro to generate code that matches the new signatures.

How Has This Been Tested?

All library and integration tests pass. Schema snapshots were regenerated.

Breaking Changes

Most users won't be affected because the #[task_handler] proc macro generates these methods automatically. Only manual ServerHandler implementations need the changes below.

// Before
Ok(GetTaskInfoResult { task: Some(task) })
// After
Ok(task.into())  // or Ok(GetTaskResult { meta: None, task })

// Before
Ok(TaskResult { content_type: "application/json".into(), value, summary: None })
// After
Ok(GetTaskPayloadResult(serde_json::to_value(&result)?))

// Before
Ok(())
// After
Ok(task.into())  // or Ok(CancelTaskResult { meta: None, task })

// Before
Task { last_updated_at: Some(timestamp), ttl: None, .. }
// After
Task { last_updated_at: timestamp, ttl: None, .. }  // ttl serializes as null

To ease migration, GetTaskInfoResult is kept as a deprecated type alias to GetTaskResult, and both GetTaskResult and CancelTaskResult implement From<Task>, so handlers can return Ok(task.into()) without constructing the wrapper structs directly.

TaskResult is removed without a deprecation shim because its fields (content_type, value, summary) have no equivalent in the spec. This should provide a clean break, which is more straightforward than a conversion that quietly drops fields.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Schema references:

• Task: https://modelcontextprotocol.io/specification/2025-11-25/schema#task
• TaskStatus: https://modelcontextprotocol.io/specification/2025-11-25/schema#taskstatus
• GetTaskResult: https://modelcontextprotocol.io/specification/2025-11-25/schema#gettaskresult
• GetTaskPayloadResult: https://modelcontextprotocol.io/specification/2025-11-25/schema#gettaskpayloadresult
• CancelTaskResult: https://modelcontextprotocol.io/specification/2025-11-25/schema#canceltaskresult