fix(producer): prevent panic when TraceDispatcher is a typed nil

[Belyenochi]

PR Title

[ISSUE #1231 ] Fix panic caused by typed nil TraceDispatcher in producer

What is the purpose of the change

This pull request fixes a potential panic during the producer initialization when a "typed nil" is passed as a TraceDispatcher.

In Go, an interface holding a nil concrete pointer is not equal to nil. The previous check if dispatcher != nil failed to detect this scenario. If a user passes a typed nil (e.g., a nil pointer of a concrete struct implementing the interface), the check passes, but the subsequent call to dispatcher.Start() triggers a panic on the nil receiver.

To resolve this, I added a reflection-based check !reflect.ValueOf(dispatcher).IsNil() to ensure the underlying value is strictly not nil before proceeding.

Brief changelog

• producer/interceptor.go: Added reflect.ValueOf(dispatcher).IsNil() check in newTraceInterceptor to prevent initialization with typed nils.
• producer/interceptor_test.go: Added a new unit test TestNewTraceInterceptor_WithTypedNil to verify that passing a typed nil does not cause a panic.

Verifying this change

The change is verified by a new unit test case that explicitly constructs a typed nil interface and passes it to the interceptor.

• Run go test ./producer/...
• Verify that TestNewTraceInterceptor_WithTypedNil passes and no panic occurs.

Follow this checklist to help us incorporate your contribution quickly and easily. Notice, it would be helpful if you could finish the following 5 checklist(the last one is not necessary)before request the community to review your PR.

• Make sure there is a [Github issue](https://github.com/apache/rocketmq/issues) filed for the change (usually before you start working on it). Trivial changes like typos do not require a Github issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue. 
• Format the pull request title like [ISSUE #123] Fix UnknownException when host config not exist. Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test(over 80% coverage) to verify your logic correction, more mock a little better when a cross-module dependency exists.
• If this contribution is large, please file an [Apache Individual Contributor License Agreement](http://www.apache.org/licenses/#clas).