Post HTTP parser error callbacks

[bettercallsaulj]

Post HTTP parser error callbacks

Issue

HTTP parser errors were still reported too close to the transport read stack. Even after storing callback failures until HttpCodecFilter::dispatch() regained control, handleParserError() invoked message_callbacks_->onError() synchronously.

That callback can close MCP connections, destroy transports, and tear down filters. Running it directly from the dispatch/read path risks destroying objects while the current stack still depends on them.

How to reproduce

1. Build the SDK with HTTP transport enabled.
2. Create an HTTP path using HttpCodecFilter with message callbacks installed.
3. Trigger a parser error from input processing. Examples:

malformed HTTP bytes

or

an oversized/null body callback that records a pending parser error

4. In the message error callback, close the MCP connection or destroy the owning transport/session.

Before the fix, handleParserError() called the error callback immediately. That allowed teardown to run during the same read/dispatch call chain, creating a reentrancy and lifetime hazard.

Expected fixed behavior

handleParserError() now posts the message error callback to the dispatcher.

The parser state is moved to the parse-error state immediately, but user callback execution happens in a later dispatcher turn. This lets the HTTP parser, filter dispatch, and transport read stack unwind before MCP disconnect and destruction logic runs.

Regression check

A regression test should trigger an HTTP parser error and verify:

1. handleParserError() does not invoke onError() inline;
2. the callback runs only after the dispatcher processes posted work;
3. closing the connection from onError() does not destroy the active filter/transport while dispatch() is still on the stack.