zerolog prevents go runtime from "deadlocking" on my machine

Question

I've stumbled upon a very peculiar case. Apparently https://github.com/rs/zerolog prevents my program from "deadlocking".

This is an example of the program:

package main

import (
    "fmt"

    _ "github.com/rs/zerolog/log"
)

func main() {
    ch := make(chan int)
    fmt.Println(<-ch)
}

When I run this on my laptop (go version go1.16.10 linux/amd64) the program just doesn't end. When I try to run it on go playground it does hit deadlock after a few seconds though, I'm not sure why: https://go.dev/play/p/6rkw0jed-6z

My zerolog version is v1.26.0

I suspect some side effect inside zerolog library causes this behavior, but can't figure out which, and can't figure out how to circumvent it... The problem is - it's making my program unsafe to use (I'm writing a piece of code which utilizes channels a lot, and not having this "safe check" is extremely dangerous).

EDIT :

As correctly pointed out in the comments, it does seem that zerolog opens another goroutine which is not blocking.

Basically it means that I can not rely on the "checkdead" functionality of the runtime, since I don't know which package might have that side effect (spawning goroutines).

What is the safe and correct way from the receiver's standpoint to end the program if it's impossible that data will be sent into the channel?

I think the obvious answer is timeout but I don't know how much time it can take for the data to appear - but maybe that's the only way?

EDIT #2

To clarify my question and motive. So far the comments have all been in a tone that I'm asking something silly (that can not be solved - or even considered to be solved). To clarify: I'm not asking "how not write code that deadlocks". Golang has a built-in "check" that checks if code is stuck: https://go.googlesource.com/go/+/refs/tags/go1.16.10/src/runtime/proc.go#5038 . So clearly there was an attempt to a general purpose solution from the very language developers.

Obviously as practice shows, this check can be "broken". In this case by a package side effect (then again why would zerolog spawn any goroutines during the init phase is beyond my understanding). So I'm asking is there another way to come up with a general solution that could potentially account for those additional factors.

If you think there can not be such solution, well it may be true, but maybe someone has an idea.