Typical online accounts of LSP are often simplified or handwavy, or lack context, so you have to keep in mind that some of the stuff that you can find out there is not necessarily 100% representative of what was originally said. LSP comes from a computer science paper by Liskov and Wing1, where they formalize the idea of a subtype, and the notion of a type specification that subtypes need to satisfy.
In there, they establish that the specification should, among other things, specify certain properties of the methods (signatures, pre- and post-conditions), but they exclude constructors from this treatment, and add to the spec an explicit statement of type's invariant(s) to compensate (see addendum below for why).
This approach allows for more flexibility when defining subtype constructors, but the idea is that all constructors must respect the specified invariant, and that all methods must preserve it. The invariant also restricts the value space of the object, thus defining legal values (e.g., the value space underlying your Circle might be formally considered to be the value space of all floats, but the legal values for the type are restricted to nonnegative floats).
You can break an invariant without ever going through any of the methods - namely, in the subtype's constructor - by allowing an observable value that's not legal in the context of the supertype. Remember, a supertype might be a concrete class, but it could also be an abstract class (with or without constructors), or a pure interface, so it may have limited-to-no control over the initial state of the object. Also, depending on what the subtype is allowed to override, the subtype might, in principle, completely bypass any state coming from the supertype. (In fact, Liskov and Wing don't even assume a subtyping mechanism such as inheritance in their paper, so as far as they are concerned, the two types can be unrelated a priori.) So, that's one reason why you'd want to state that requirement separately.
But beyond that, yes - the methods must make sure to preserve the invariant (assuming the state of the object was legal upon entry), and it makes sense to connect this to pre- and post-conditions. However, within the context of the paper, the preservation of the invariant is treated as an implicit requirement for every mutator method, and so, the invariant itself is not formally counted among the explicitly stated pre- and post-conditions. It's more that you want the pre- and post-conditions to be compatible with the invariant, in the sense that its preservation follows from them. (Again, see the addendum below for additional context.)
As an example (modified from the paper), an invariant for a collection type (like a list or a vector) might be "lenght ≤ maxLength". On the other hand, the type's add(item) method might have the precondition that the "length is not equal to maxLength", and the postcondition "contains all the previous elements + the new one, and maxLength has not changed". You can then show that the invariant is preserved because the length is only increased by one, and only if the collection is not already full.
Now, given an incorrectly implemented subtype, it is possible for the corresponding add(item) method on the subtype to preserve the invariant, but violate the supertype's postcondition - say, buy simply ignoring the input. Explicitly placing restrictions that ensure compatibility of pre- and post-conditions ensures that the subtype's methods exhibit the same behavior as the supertype, when used in a context that expects the supertype (or rather, anything adhering to its spec).
Addendum: Another way to get some insight into why Liskov and Wing went about it in this particular way is to understand that they are sort of creating an inversion of a preexisting procedure called "data type induction", a formal method used to prove various properties of a type (outside the context of subtyping). The gist of it is, to infer some new, unstated but interesting or desirable property of the type, you'd start by demonstrating that it holds after construction, establishing your base case, and then proceed to prove that it remains true for the inductive case, for some method, by using other known properties, such as pre- and post-conditions. If such a property remains valid no matter what operation is applied, then it's an invariant. Again, in this context, this would be something that's inferred, something potentially not obvious in the code itself, not found among the explicitly stated properties of the type, method postconditions, and such. Well, Liskov and Wing don't allow constructors in the spec, meaning you can't establish the base case, so such invariants can't be inferred by this procedure - instead, you explicitly state in the spec what you want to be true of the type.
1 Liskov and Wing (1994) - A Behavioral Notion of Subtyping; https://doi.org/10.1145/197320.197383