Lodash debounce cancel() limits: what happens to an in-flight async call from the leading edge

I'm designing a search input handler around _.debounce (Lodash 4.x) where the debounced function is async and triggers a network request. I plan to call .cancel() when the user navigates away or clears the field.

The documented behavior is clear that .cancel() suppresses any pending trailing-edge invocation. What is less clear to me is the boundary of that guarantee: with leading: true, a call may already be in flight when .cancel() runs, and since Lodash treats the debounced function as synchronous, the returned Promise appears to be outside Lodash's control entirely.

My constraints: I cannot undo a request that has already been sent, and I want to avoid state updates from stale responses after cancellation. I also want to know whether relying on .cancel() alone is sufficient, or whether cancellation of the async work itself must be handled separately (e.g., an AbortController I manage alongside the debounced wrapper).

Specifically:

1. Does .cancel() have any defined effect on a Promise returned by a leading-edge invocation that is still pending, or is that Promise guaranteed to settle normally?
2. Is there any documented interaction between .cancel() and the leading/trailing options that changes this behavior?
3. Is managing an AbortController outside the debounced function the intended pattern, or does Lodash offer anything built in for this case?