I think it’s not a by chance that there’s no convention and few articles about that in rescript/ocaml or functional languages in general. A big motivation of dependency injection comes from the characteristics of Object Oriented Programming itself.
In OOP the base brick is objects/classes, you have side effects and local states everywhere, you need dependency injection to mock the local states and side effects and test things in a given set of local states. In functional programming, most things are immutable and side-effects are much less common. You can easily test things in isolation and if some functions are pure and tested, you can fully trust their combination. Try to stick side-effectful functions to the edges, test them with simple dependency injection (simple function passing is usually enough, but use some first-class modules if you absolutely need to, I think it’s a bit more idiomatic than records of functions then), then write pure (no side-effects) functions you can test easily without dependency injection.
Trying hard to replicate things that come from other paradigms is usually not a great idea, you try to solve problems that mostly don’t even exist, so why even bother? My advice with functional programming is usually to follow the basic conventions (gather functions in modules around their main type t) and see how far it gets you. I’ve been working with OCaml/rescript as my main languages at work for the past 5 years and never really felt the need for more complex architectures. You can find some huge OCaml projects that are 25 years old and still use very simple architectures and basic concepts in general.