Start obsoleting the usage of IncomingMessage on the error context

[danielmarbach]

Follow up on #7662

This PR flattens the relevant IncomingMessage data onto the pipeline and error contexts.

Instead of requiring consumers to go through an IncomingMessage instance to access message details, the contexts now expose the message information directly. This makes the pipeline/error context the primary surface for message-processing state and better reflects that IncomingMessage is created as part of the pipeline flow, after envelope unwrapping.

Motivation

During review, it became clear that IncomingMessage should be treated as a pipeline concept. The envelope unwrapper is responsible for creating it from the transport-provided message context, which means the pipeline context already has the information needed to represent the message being processed.

Given that, carrying an IncomingMessage object around as the main way to access message state makes the context model less clear. The properties that are needed by pipeline behaviors and error/recoverability handling belong directly on the corresponding contexts.

This also avoids having Core duplicate preservation logic around nested message objects. The transport provides the original message data, the pipeline creates the incoming message representation, and the contexts expose the relevant message state directly where it is used.

Changes

• Moves the relevant IncomingMessage properties onto the pipeline context as flat context properties.
• Moves the relevant failed-message properties onto the error/recoverability context as flat context properties.
• Updates message handling code to use the context-level properties instead of reaching through an IncomingMessage.
• Updates recoverability and error-handling flows to access failed-message data directly from the context.
• Keeps the envelope unwrapper responsible for creating the incoming message representation from the transport message context.
• Updates tests to reflect the new context shape and verify the same message data remains available during processing and recoverability.

Behavioral impact

There should be no intended behavioral change in how messages are processed, retried, or moved to the error queue.

The change is primarily a context-modeling refactor:

• message data remains available during normal pipeline execution;
• failed-message data remains available during recoverability/error handling;
• the data is now exposed directly on the relevant context instead of being accessed through a nested IncomingMessage.

This makes the ownership boundaries clearer:

• the transport provides the raw message context;
• the envelope unwrapper creates the incoming message representation;
• the pipeline and error contexts expose the message state needed by behaviors and recoverability actions.

[danielmarbach]

Small follow up #7743