Describe the bug
sorry if this text is a bit confusing, it has been many hours of debugging until I realized this may be an issue with redis.

The documentation for RedisModule_UnblockClient is either incorrect or something does not add up in how to use the function when blocking a client with RedisModule_BlockClientOnKeys.

Due to issue #7878 I am using the function above as a workaround for unblocking the client. In this case the client is unblocked as expected, and this time as the documentation states (confusingly since it first talks about reply callback then clarifies that it is the timeout callback) it calls the Timeout callback instead of the reply callback (https://redis.io/topics/modules-api-ref)

Note 2: when we unblock a client that is blocked for keys using the API RedisModule_BlockClientOnKeys(),
the privdata argument here is not used, and the reply callback is called with
the privdata pointer that was passed when blocking the client.

Unblocking a client that was blocked for keys using this API will still require
the client to get some reply, so the function will use the "timeout" handler in
order to do so.

The problem is that the signature of the timeout callback is this one (in zig):

fn TimeoutReplyCallback(ctx: ?*RedisModuleCtx, argv: [*c]?*RedisModuleString, argc: c_int) callconv(.C) c_int

There is no privdata argument in the signature, so that must be a mismatch with the documentation. But the biggest problem is that if you try to get the privdata with

    const pData: *ReplyData = @ptrCast(*ReplyData, RedisModule_GetBlockedClientPrivateData.?(ctx));

pData will always be NULL. Therefore it becomes impossible to access the privdata in this scenario.

I am missing something?