Make fast thing look slow (Box2D)

Instinctively I'd say that we're missing a substantial part of the context needed to answer, which is "why does the multiplayer aspect prevent you from changing the timestep?"

If you are trying to share a physics simulation over a network connection, well, that's usually a pretty hard thing to do. The simulations diverge very easily, and especially with network connections that can lose packets, it's very hard to keep things together.

The simple and most robust answer to your question is to use a variable timestep. When you approach the moment of decision, instead of updating your physics simulation by one second for every real-world second that passes, update it by half a second, or another suitable number. As it's an integration effect, you'll probably be able to get away with simply snapping the update rate down to the lower rate during the decision window, but you can also interpolate quickly downwards to the lower rate. Either way, you are essentially playing back the physics simulation in slow motion. It should behave perfectly accurately, just slow enough that the player can make their decision. I wouldn't consider any other means of fudging the physics to make it work, they'll most likely all work out horrible and not feel 'right'. Keep the physics pristine, and counter the decision window problem outside of the simulation.

So we come back to the networking implementation. Without further information, I'd guess you have two choices. Firstly, if you're operating in lockstep with the other networked party. So when one player has to slow down to make their decision, slow down both players equally. This will probably feel annoying and weird for the player who isn't firing, because it'll confuse their own reaction times.

For the second, imagine two trebuchets firing at each other. The trebuchet takes 10 seconds to throw, and the firing window starts at T+5s. P1 starts the firing cycle at T+0s, and at T+5s slows their local physics simulation down by 50%. It'll take them 15s to play through the whole cycle. So at T+5s, P1 tells P2 to start playing back the 10s launch cycle at full speed. So P1 sees the trebuchet cycle take 15s, P2 sees it take 10s, but both players see the cycle finish at T+15s. When P1 actually releases, they tell P2 when in the notional cycle they released. So if P1 releases at T+10s, that's actually at 7.5s through the 10s launch cycle. P2 can then show the release at T+12.5s (7.5s into its local playback of the cycle), and both players simulations should have launched the projectile at the same physical point in the cycle.

So in this second approach, you're no longer simulating in lockstep. You're running two independent simulations, but tracking player inputs instead. If both are told that the player released at 7.5s into the launch cycle, they should both agree on where the projectile will land. In practice though, that's likely to diverge very fast, and you're going to need to synchronise simulation states somehow.