Scrum is an empirical control process, and therefore "big, upfront planning" is intrinsically an anti-pattern. But Scrum certainly includes a lot of iterative and just-in-time planning, along with a predictable cadence and a set of inspect-and-adapt events when the framework is properly applied.
Scrum Uses Iterative, Just-in-Time Planning
Neither a "forecast" nor a "commitment" provides you with a money-back guarantee. In either case, it's an educated guess as to what is likely to be accomplished during an iteration.
With the 2020 Scrum Guide, the word "commitment" has made a return, but it still doesn't say what you may think it does. For example, regarding forecasting (emphasis mine):
Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these [forecasting practices] do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.
The new guide also contains several types of explicit commitments, including Product Goals, Sprint Goals, and Definition of Done. The commitment to the Sprint Goals says in part (again, emphasis mine):
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives
In other words, the Scrum Team Developers commit to working towards the Sprint Goal. While doing so, the whole Scrum Team keeps the Product Goal, Sprint Goal, and Definition of Done in mind in the way they attempt to produce the Increment.
Commitments Are Objectives, Not Money-Back Guarantees
None of the foregoing adds up to traditional accountability (pronounced "blame") in the way it's meant under Theory X management. The various Scrum Team commitments aren't money-back guarantees that the Increment will be finished with an implied "or else!", or that the completed Increment is guaranteed to be fit-for-purpose. Instead, it's a commitment to include the various framework goals and artifacts in mind throughout the development process. This doesn't guarantee a successful outcome; it simply guarantees that the iterative, just-in-time planning processes that Scrum's empirical control framework embodies contains measurable goals against which progress (or lack of same) can be measured, evaluated, and acted upon.