SOLID.LSP + OOP.Polymorphism = contradiction?

Question

OOP

After studying various sources about the Liskov Substitutioin Principle , I did not find an answer to the question:
How does LSP combine with polymorphism in OOP?
After all, judging by the definition, LSP instructs the heirs to preserve the behavior (contract) of the base class.
Whereas polymorphism is the ability to change the behavior of the methods of the base class in the heirs. If we interpret LSP literally, then I see an unambiguous contradiction in these approaches.
Actually, how to resolve it?

Answer 1

LSP instructs descendants to preserve the behavior (contract) of the base class.

Not behavior, but limitations. LSP only allows you to increase the requirements for yourself, and only weaken the requirements for others. Behavior can change as you like within these restrictions.
For example, the Stream interface allows multiplexed streams (that is, streams where we cannot read what has been written, reading and writing go through different channels and are not connected to each other in any way - for example, COM ports), and some BufferedStream is limited only to streams, where we write to some byte chain (for example, a file), and read from it, without multiplexing.

Answer 2

There was a requirement - to change the format of some reports to CSV.

And who said that there might be such a requirement? Or rather, that you can satisfy him without changing the contract?
What contract do you have? What does the MakeReport method return an html report? So how can you even implement a CSV return without changing the contract?
But if you do change the contract, for example, say that "MakeReport returns a stream (text or binary) of a finite size", then the generation and return of CSV will fit into such a contract. Of course, such a contract will already be much more general - there will even be nothing special to test in it (except that the report was generated at all and has a non-zero length).
On the other hand, who is stopping you from writing tests for specific implementations of this contract? After all, unit testing is also modular, which can know more specifics about a single module.
It's simple, isn't it?
The substitution principle says - I will put a framework, restrictions (ie contract), and all instances of subclasses must satisfy it. Polymorphism says great, which means we have the ability to define a SPECIFIC behavior that may differ from other specific behaviors, but at the same time they will all do something quite expected and PRE-AGREED.
The very fact that you make AGREEMENTS that the clients of the class expect, gives you the right to behave AS YOU WANT (well, I exaggerated a little, but the essence is this) in each of the subclasses in ALL OTHER aspects.

Answer 3

Whereas polymorphism is the ability to change the behavior of the methods of the base class in the heirs

Pretty strange statement. Polymorphism is more of the ability to interchange types. That is, both class A and class B can be passed to the method: A.
The LSP principle is just about how best to achieve this