Warning: lots of stereotypes follow.
Rust believes APIs should be [close to] impossible to use incorrectly. So we get rich type system, contracts, and other kinds documentation. All corner cases are either impossible because of the type or explicitly written down in the contract. If UB happens because user wrote incorrect code, that's a library's bug because it did not defend against it.
C believes the programmer. Documentation typically mentions happy path and some popular errors only. Lots of assumptions are implicit, like thread-safety, reentrance, (lack of) NULLs, lifetimes of inputs/outputs. It's up to the user of the library to figure out restrictions if their usecase is not in the documentation. Common sense and knowledge of C traditions helps. If UB happens because the user did something a bit out of the usual, it's on the user.
That brings us to different mindsets of library developers.
In Rust you typically write code while proving that it's correct in all theoretically possible cases, otherwise the code does not even compile. If it becomes too hard, you refactor API, possibly making the implementation harder. But your API is kind of nice in the kind.
In C you take whatever piece of code you found to be useful, extract it in a function or two and use in the project. If you happen to need that exact code somewhere else, you use it. There is no need to prove that the code always works or that it's a sound abstraction. If it works, it works. If it stops working in some case because of a bad API design, then you decide whether it's worth refactoring or not. That makes the initial implementation simpler, but it lacks contracts by design.
So I attribute it to cultural differences between "C programmers" and "Rust programmers". For Rust programmers, "full function contract" is a must, so documenting it seems easy. For C programmers, "full function contract" is not required for writing working code in 95% of cases, so documenting it is extra chore with no benefit.