pkg/tools/batcher: stop scheduler panicking when b.data is closed externally

[SAY-5]

Fixes #3653.

scheduler()'s defer unconditionally calls close(b.data). If the channel was closed by the caller (or an upstream producer) instead of via the normal Close()-sends-nil path, the receive on b.data returns ok == false, scheduler returns, and the deferred close(b.data) then fires on an already-closed channel:

panic: close of closed channel

reliably reproducible under the issue's steps (manually closing b.data while Start() is running).

This tracks whether we observed the external-close via a local externallyClosed flag set in the ok == false branch. The defer only closes b.data when that flag is false, i.e. when the scheduler exited through the nil-message or ticker paths and still owns the channel. No behaviour change on the graceful Close() path.

[github-actions]

🤖 All Contributors have signed the CLA.
The signed information is recorded here
_{Posted by the CLA Assistant Lite bot.}

[SAY-5]

I have read the CLA Document and I hereby sign the CLA

[SAY-5]

Both failing checks look unrelated to this diff:

• Benchmark Test: check num:40, conversation num un correct, userID=test_v3_u18, ConversationNum=5, correct num=7, this is the integration counter checker in openim-sdk-core/integration_test failing on a state-setup race, not anything in pkg/msggateway.
• Build and Test Dockerfile (1.22): same overall run failure, no diff-related compile errors.

Happy to rebase or rerun if it'd help; the changes here are scoped to the WebSocket compress-buffer release path.