Log parsed trace_id from traceparent header

It's currently difficult to correlate distributed requests across services using only logs. While the `traceparent` header (W3C Trace Context) provides the necessary context, directly logging the `trace_id` component would be the most effective way to enable log-based trace correlation.

When an incoming HTTP request contains the `traceparent` header:

1. Parse the header value according to the W3C Trace Context specification.
2. Extract the `trace_id` portion.
3. Include this extracted `trace_id` value in the corresponding request log entry.

For example, if the header is `traceparent="00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01"`, the log entry should include a field like `trace_id="0af7651916cd43dd8448eb211c80319c"`.

Logging the full `traceparent` string is an alternative, but logging just the `trace_id` is often sufficient for correlation and can result in slightly cleaner/more focused log entries.

This allows direct filtering and searching of logs using the `trace_id` in log aggregation systems, significantly improving debugging capabilities and observability for distributed traces.

c.f.
Some cloud providers support their own log format for trace id:
Google Cloud "trace" or "logging.googleapis.com/trace" [Structured logging](https://cloud.google.com/logging/docs/structured-logging)
AWS aws.cloudwatch_logs.log_group [AWS resource data](https://docs.aws.amazon.com/xray/latest/devguide/xray-api-segmentdocuments.html#api-segmentdocuments-aws)

Start at the incoming HTTP request logging entry point and trace how request headers become fields in the corresponding log entry. Use the W3C traceparent example to verify that the extracted trace_id is logged for requests carrying that header, and confirm behavior for requests without it.

Written by the indexing model from the issue text.