Welcome to real business.
There is an older style of business, which I tend to derisively call "traditional development" and then there's a new style, "agile development." If I try to treat these as opposing ideals, we see a straightforward division down the middle: plans and requirements go on the traditional column, discovery and evolution go in the agile column. It's neat, tidy, and wrong.
In reality, business is a search for the happy medium between the two. It's easy to show that either extreme actually falls flat on its face. We who love Agile eagerly demonstrate all the issues of the pure ideal of traditional development, and there are plenty who can show the many ways pure Agile falls apart. The successful agile companies are the ones that find their particular balance between the two. The successful traditional companies are the ones that find their particular balance between the two. You can't have one without the other.
Even our blessed SCRUM process shows a balance between the two. While there is a clear attempt to maximize agility, there are a few key tradeoffs made. For instance, the Product Owner has the mighty job of advocating for all of the customers. SCRUM intentionally does not specify how that interaction works. It intentionally handwaves over the fact that everyone needs to get paid at the end of the day. Its' the Product Owner's job to create the illusion that that doesn't matter.
(Its interesting to note that pure agile works great, so long as you don't get paid until you produce a product, and you don't get access to proprietary information until you are vested. I think the only software engineers that are comfortable with this trade are the entrepreneurs)
So the management has dictated what features will be in there and when they need to be there. That's fine. A phrase I have heard is "the customer picks the what and the when, the producer picks the who and the How." You've been signed up for the "what" and the "when." They have not stated anything about the who or the how, other than to offer you a chance to use "Agile" as your how. All that's left is to help management understand how many people they are going to need to hire to meet their needs.
In a perfect world, your company is agile from the outside. It interacts with its customers in an agile way, letting the developers develop agily for them. However, very often the company must interact with the outside while developing agily inside. In between is always a complex set of tradeoffs, unique to each company.
Personally, I treat this situation as a test case for anyone who thinks they understand agile development. At some point in the future, you will have to develop a product for a deadline, and that product/deadline pair will be relatively fixed. If a fixed product/deadline shatters your process, can you truly say you were Agile in the first place?
My advice: don't think of this as a waterfall. You still control the "how." You can still do all of the rapid sprinting and flexible prototyping that Agile is so famous for. You merely have to be aware that the rubber meets the road, and you have to deliver. This is the real world, not the ideal world. Would it have been better for them to ask you in the first place? Sure. It may not have been your call. There may be a thousand business-related reasons to do it their way that you simply do not fully understand. Feel free to push back on them, but understand that they may have a very good reason for what they did.