> Contractors never say no.
No. :-)
If the contractor/consultant was good, what you are likely experiencing is at the endpoint of a longer and larger process. Behind doors closed to you, in the procurement meetings you probably aren't privy to, the PM is presenting to the contractor a set of constraints that presume your adverse timeline.
The good contractors will point out drawbacks A, B, and C if the time constraint is not relaxed. A manager somewhere will likely dismiss that and say "we understand and accept the tradeoffs". Usually that is exchanged over email because the contractor wants a paper trail. And usually that exchange never is shared with the technical staff, much less make it into the project documentation. This is poor leadership (and in human nature), ostriching away inconvenient engineering realities, and in my experience one of the primary reasons you end up with what you described.
There are crappy body shop-supplied contractors, to be sure. But you usually can exert a veto at the technical vetting stage over that. However, it is the rare organization that includes the technical staff in the entire procurement process.
You are also possibly not communicating your "no" effectively enough. Usually this happens when your efforts at managing upwards and drawing boundaries are not getting the attention you desire.
You can fix this in all but the most egregiously dysfunctional organizations, but it is hard work for most technical individual contributors, because it requires developing social, communication and emotional skills that are difficult to master for anyone. The remedy delivery varies on a case-by-case basis. Sometimes it is as simple as working with the contractor to ring fence the solution they are procured to deliver, deliberately treating everything the code touches as tainted through specially marking it in debugging output so you can easily troubleshoot it later. Sometimes you have to wade into project management meetings and explain in ELI5 language without sounding condescending the tradeoffs being juggled, and hold accountable the decisions without letting a hint of "I told you so" creep into your tone.
You will always have to ensure you stay on top of what you are working on now, what you plan to work on in the pipeline, time commitments for each, and be able to tell week to week the impact on delivery timelines for everything based upon recent developments, and boil it all down to management as "if we do this, then that means these other goals will delay by this much", where the goal is expressed in business terms when possible. Yes, this means you are doing project management. Yes, this means you are doing much of the work of your project manager. Then why have a project manager, you ask? Because their job is not to help you; that's mostly incidental if it happens. Their job is to help communicate what is happening in the project to your managers.
As a young whelp, I used to have a "c0d3 == l1f3" approach to my work, and doing any of this other work was sheer agony, as I sucked at it at first. It got a lot easier for me when I modeled all of it as different communications protocols with different manager types, and experienced that if I put in the work to reach out with these different communications styles, lots of managers became my enthusiastic sponsors (and by extension, when I made the jump to consulting, this helped my selling skills). YMMV, of course. Hope this alternate perspective helps.