I would be careful about making std::bit_int a library type. A driving reason for this to exist in C is to start using this fairly aggressively in bitfields, and many vendors embedded and not have made it clear they want to do this as an extension and improve the story for bit-fields in this around C. Insofar as I understand it, having std::bit_int as a class template would make it very, very difficult to coordinate in this fashion without some interesting language surgery to allow this type, specifically, in bit-fields. (Imagine similar to the wonky compiler internals to, specifically, bless std::byte, but much more thorny.)
One serious additional benefit of not making this a library-driven feature as well is that a compiler is allowed to step on the "padding bits" of a C _BitInt; a std::bit_int that has to fill the padding bits with unused bytes can't reasonably be understood by a normal compiler as having those unused bits in class members contain irrelevant padding values, and so any clever size optimizations go into the trash without compiler special casing or new techniques to mark parts of a structure as containing padding bits.
In short: please consider putting this into the language. While the functionality can be approximated as a library type, you may run into many thorny niche-but-nonetheless-important problems if such information is not encoded directly into the compiler.