This flat_map method takes a FnMut implementaton but the Parser implementation requires a Fn implementation. Putting the closure directly in the flat_map invocation poked the compiler in the direction of deciding your closure should be a FnMut closure only, and not the more general Fn closure.
Poking the compiler to decide certain things about a closure by putting it directly in a function invocation is helpful in overriding inference in some cases, but in this case, it backfired. You can add your own helper to counteract it in this case (shown in the playground below).
When I'm faced with complicated Rust code and I'm not sure what the type of a given value is, I can usually just do this:
let _: () = the_value;
And the compiler will tell me. When it comes to failing trait bounds, the analogous option is to set up your own function with the trait bounds and feed values through it, so you can get more details about what's breaking.
fn helper2<I, O1, O2, E, F, G, H>(f: FlatMap<F, G, O1>) -> FlatMap<F, G, O1>
where
// vvv the bounds from the `impl Parser for FlatMap`
F: Parser<I, O1, E>,
G: Fn(O1) -> H,
H: Parser<I, O2, E>,
{ f }
Usually that's enough to get the information you need, but when it isn't, you can start eliminating bounds to hone in on the problematic one.