Reauthorize tools changed by call-tool filters

[PranavSenthilnathan]

Summary

• add one ordinary authorization filter for each AddAuthorizationFilters() registration so intervening call-tool filters can replace and reauthorize the matched tool
• remove the Tasks registration-order restriction because ordinary filters run inside task execution regardless of when they are registered
• preserve authorization reevaluation at every explicit checkpoint, including changes to the matched tool or user
• add regression coverage for tool replacement and for ordinary filters registered before Tasks

Note

Tool authorization is intentionally not performed at the outer task-dispatch level. A caller may register a filter that replaces the initially matched tool before the next authorization checkpoint. Authorizing outside the ordinary filter pipeline would instead authorize—and potentially reject—the original tool before that replacement can occur. For task-backed calls, this means task creation can precede authorization during background execution.

Closes #1733

Testing

• dotnet build
• dotnet test tests\ModelContextProtocol.AspNetCore.Tests\ModelContextProtocol.AspNetCore.Tests.csproj --no-build --filter "FullyQualifiedName~AuthorizeAttributeTests|FullyQualifiedName~HttpTaskIntegrationTests"
• dotnet test --no-build (all ASP.NET Core tests pass; existing Core integration tests fail because TestServer.exe is not available on PATH)

[halter73]

This drops the authorization pass outside Tasks. An anonymous call to an [Authorize] tool now reaches CreateTaskAsync and gets a task ID, which regresses #1722 and #1733's requirement that denial happen before task creation. Can we keep one alternate-result authorization check before Tasks and add this ordinary checkpoint alongside it?

[halter73]

Can this also cover a task-backed call where an ordinary filter replaces an anonymous tool with an authorized one? The direct call proves the new checkpoint order, but not that the replacement is reauthorized inside Tasks.