Fix early request cancellation race

[dariuscorvus]

Summary

• track incoming request dispatch tasks before handler registration so immediate notifications/cancelled messages cannot fall through the registration gap
• cancel both dispatch and active handler tasks atomically, retain token-based ownership during cleanup, and suppress late responses even when handlers swallow cancellation
• reject duplicate outstanding request IDs across standalone and batch requests
• process the built-in cancellation handler before logging and application notification handlers can suspend
• cancel tracked work during stop() and avoid duplicate built-in cancellation handler registration across restarts

Tests

• DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer swift test --filter CancellationTests
• DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer swift test
• 554 tests in 40 suites passed
• git diff --check

Motivation

The receive loop spawns request processing asynchronously. Before this change, a cancellation notification could be consumed before the request's handler task was inserted into pendingRequestTasks, causing the cancellation to be treated as unknown. A deterministic HTTP-context barrier test now covers that exact ordering.