As established by you and other answers, you don't sit in the right position in the chain of command to reprimand Jim. That's where that track ends.
However...
Jim takes it upon himself to call them directly and “kindly coerce them” into doing it
There's your opening.
Jim likely does not have the authority to override your authority vis à vis engineer staffing and scheduling. He's interrupting your management.
Let's us a simpler example: if Jim promises a free yacht to every customer, is it your fault for failing to deliver that yacht? Nope.
The same principle applies to Jim making promises to customers about engineer availability. He gets to make whatever promises he wants to make, you don't get to stop that. That's his job. You do, however, have to abide by reality, and cannot be held responsible for Jim's unfounded promises. If his promises fall through because he asked for something that could not reasonably be delivered, that should blow back on Jim, not you or your engineers.
The first step here is to stop entertaining Jim's folly. Don't bend over backwards to make their dream a reality. Get your engineers to work their scheduled hours, and stop everything that goes beyond that.
“kindly coerce them”
Have your engineers concretely explain how this coercion takes place. What does he tell them?
Empower your engineers to not agree to anything Jim says, instead redirecting every request to you (or another relevant authority who is willing to hold Jim to account for their request).
Whenever any request goes out of bounds, indicate that you cannot deliver the request. Don't provide more information than you have to. The more information you provide, the more openings you give him to argue with you. State very clearly that e.g. the current schedule is already full and your engineers cannot commit to more work at this time.
Whether Jim already promised the customer or not is inconsequential. He doesn't manage the engineers, you do. Without your say so, Jim has no reasonable expectation on what the actual availability is.
What to do? Did anything like that ever happen to you? How did you make it into a win-win scenario?
I'm in software development (it's unclear what kind of engineers work for you). Non-technical leadership making calls without any kind of technical expertise backing their decision is the daily bane of people in my position.
Simply put, I engineer a discussion format that makes it very clear what the consequences of the decisions are.
For example, I don't let people add extra work into an established sprint. There are a given amount of manhours in our sprint (based on 2 weeks, developer presence, and their contracted working hours).
If ad hoc work is urgent, I don't block it. But I have a list of all the work, both scheduled and on the backlog, and it's ordered by priority, with a clear marking for the cut-off point of what can be done within the given sprint. Simply put, when they drag something upwards, everything else sinks down in priority.
This avoids the issue of accepting to help out on an urgent issue, and then later having to explain why the original deliverable was delayed. Instead, it makes it very clear at the time that prioritizing one deprioritizes another.
I give people trust until they breach it, and when breached, I stick to the formalities of availability scheduling. At the end of the day, I can stick to "the sprint has locked down, we can look at it next sprint at the earliest". In reality, I do accept doing things ad hoc, but only because the requests are reasonable and are met with the understanding that this delays the original sprint goals.
Jim has very clearly achieved that status, so you should stop trying to do whatever hare-brained idea he has cooked up for you. Stick to your schedule.