Clarification on Trace ID Behavior in Bulk Topic Subscription (Dapr SDK 1.17.0)

Hi Dapr Team,

We recently upgraded from Dapr SDK 1.16.0 to 1.17.0 and migrated from the alpha onBulkTopicEventAlpha1 (deprecated now) to the production onBulkTopicEvent API for bulk topic subscriptions. We have a question regarding trace ID propagation in bulk operations.

Our Setup:
- Dapr SDK: 1.17.0
- Implementation: Java gRPC-based subscriber using AppCallbackGrpc.AppCallbackImplBase
- Method: onBulkTopicEvent(TopicEventBulkRequest, StreamObserver)

Current Observation: When we call the onBulkTopicEvent endpoint (testing via Postman), we observe that there is only one trace ID in the gRPC response metadata for the entire bulk request, regardless of how many CloudEvents entries are in bulk.

Our Questions:

 1. Is this expected behaviour? Should onBulkTopicEvent provide a single trace ID for the entire bulk operation, rather than individual trace IDs for each Cloud Event entry?
2. Individual event tracing: If we need distributed tracing at the individual event level (to track each event separately through our system), what is the recommended approach?
3. Best practices: What is the recommended pattern for maintaining observability and tracing for individual events within a bulk subscription operation?

Context:
      We previously used onTopicEvent (non-bulk), where each event had its own trace ID. Now with bulk processing, we want to ensure we maintain proper observability for each event while benefiting from the performance improvements of bulk subscriptions.

Any guidance or documentation references would be greatly appreciated!