[feat] HTTP ingress

[FerroO2000]

Summary

This issue proposes the foundation for request/response ingress stages, starting with an HTTP ingress based on standard library, while preserving the pipeline's one-way dataflow model.

The main idea is to carry only a lightweight correlation ID through message.Message, and keep the actual response future state at the HTTP boundary.

Design

• Add a correlationID field to message.Message.
• Propagate the correlationID automatically when a processor creates an output message.
• Introduce an HTTP Exchange shared by the HTTP ingress and HTTP response egress stages.
• Store pending response futures in a sharded FutureRegistry owned by the Exchange.
• Let the HTTP ingress create a future, assign its ID to the message, write the message into the pipeline, then wait for completion with a timeout.
• Let the HTTP response egress resolve the future by reading the message correlationID.

This keeps futures out of message bodies and avoids leaking HTTP-specific concepts into intermediate processors.

Lifecycle

• Pending futures are removed when resolved, rejected, or timed out.
• Stage shutdown rejects all pending futures so blocked HTTP handlers can return cleanly.
• The HTTP request context is not passed through the pipeline; request data is copied into the message body.

Notes

• The registry should use sharded maps to avoid a single hot mutex.
• Each future should keep its own done channel for precise wakeups.
• A shard-level condition variable was considered, but rejected because broadcast wakeups could create unnecessary scheduler churn under load.