The issue is that the keywords "posedge" and "negedge" in Verilog (or "rising_edge" and "falling_edge" in VHDL) have very special meaning to the synthesizer. The synthesizer gives every signal attached with these keywords a dedicated clock routing network on the FPGA. Do not use those keywords for any signal that you do not want connected to a clock routing network on the FPGA (which obviously, should be no signal other than a clock).
It is a great waste to use one of the precious few dedicated clock routing networks on an FPGA just to have an asynchronous reset. I know of no way around this and the solution is to actually just not use asynchronous resets at all. Just use synchronous resets.
The use of asynchronous resets appears to be a practice that was carried over from ASIC design early on that has been misapplied to FPGAs and repeatedly taught turning it into a bad habit. Asynchronous resets have advantages in ASIC design that do not carry over to FPGA design due to the hardware constraints of the FPGA. One such advantage is saving gates which you can do in an ASIC since you have control over everything, but in an FPGA the flip-flops are already there and all have a clock input anyways so you save nothing.
It is interesting that asynchronous resets in FPGAs also monitor the clock signal as well. You would think this would not be necessary since the reset is asynchronous, after all, so why would it ever need to trigger on a clock at all? The reason is because if the asynchronous reset deasserts too soon after a clock edge, there are metastability issues because timings are violated. A true asynchronous reset (as one that might appear in an ASIC which is where the practice came from) would not need to also trigger off the clock to stop this from happening.
The only weakness I have been able to find about synchronous resets is that if you have multiple clock domains and improperly use the synchronous reset with only the higher speed clocks in mind, it is possible for the slower clock domain to miss the reset pulse since the reset deasserts before the slow clock can tick to register the reset pulse. However, you can protect against this by design and I do not think it is a big deal compared to using a dedicated clock routing network for something so trivial as an asynchronous reset.