The problem is that you don't really have subtype polymorphism here. While the language permits it, it is poor practice to change the interface (set of public methods) as you move down the hierarchy. I'm not speaking of the formal interface but only of the messages that an object is allowed to handle. Your class Vehicle doesn't have honkHorn, but a subclass does.
The problem with this is that if I have an object, I need to know its specific type to know what methods it supports. Some Vehicles support honkHorn, but others don't so I need to test.
This is, at best, ad-hoc polymorphism.
If you want true subtype polymorphism define a class as an interface or abstract class as you have done here, but all subclasses should exhibit exactly the same interface.
Then, if you define a variable to have the interface (abstract class) type, then it can refer to any object of any subclass and it can field any message defined at the top level. You never need to ask instanceof and you never need to cast.
It is, of course, harder to build a system keeping such a pure rule, but it can be done and it saves you a ton of grief later.
One of the reasons we want to build OO software is to let the system figure things out without explicit testing. If you change "interfaces" within hierarchies you are just back to ad-hoc decision making. You are defeating the notion of IS-A that the OO paradigm was built for.
In your example you can't really say that a Bicycle IS-A Vehicle. You can say that it is a Vehicle, but something more, and we have to determine what by ad-hoc means in many instances. Sometimes by declaring variables to have a specific type (rather than a general type) and sometimes by testing.
In terms of "contracts", if you change the contract as you come down the hierarchy, it wasn't really a contract.
Sadly, too many books don't understand this and define meaningless, and difficult to work with, "hierarchies".
One way to avoid this issue, is to define Vehicle as an interface and then define Bicycle as another interface that extends Vehicle. Now your intent is clear. Classes implementing an interface have only the public methods defined in their interface and nothing more. Now you have interfaces of concepts which is what they are really intended to model, and classes of objects that conform to specific concepts. This may be the mental model you seek, actually.
I discussed Polymorphism at some length here: https://cseducators.stackexchange.com/a/4050/1293
Let me add some things here to point to a better way. One of the lessons is that subclassing is generally overused. Some books present it as the "really big thing". Instead, programming by composition is much more valuable. When you create a class give it parts that are instances of some other, simpler, class.
For the immediate problem here. Give Vehicle a method makeSound. Give each subclass of it an instance field that refers to some kind of object that might make a typical sound. For a bicycle object it might be a Horn object. Then when any vehicle is sent the makeSound message it delegates the making of the sound to the object that is part of its composition. Delegation is the big idea here. Now you don't need to change the protocol in different classes. Just change the implementation, but giving different "parts" to different vehicles.
At least one very commonly used book has something like the following hierarchy. First a Point class. A point has some coordinates. Then, for the first (ugh) example of subclassing is a Circle class. This is "easy" to write, since if you subclass Point all you need to add is a radius value. But to a mathematician, is every circle a specialization of point? It is backwards, of course. Taking it farther, a Cylinder can subclass Circle just by adding a height value. This makes it very easy to type in, but very foolish, both mathematically and from a program design standpoint. If you create a Cylinder, what sort of variable should you use to refer to it. If you don't use a Cylinder variable, then within the next few lines you are very likely to have to cast the variable, or, if you have put such things into a List then you are going to have to type case them (or equivalent) when you look at them again. Don't do that. But what can you do better. Use delegation.
When you build your Circle class, don't make it an extension of Point. Instead, give it an instance variable of type Point. A Circle is a different kind of thing. It isn't a point, but it HAS-A point as a field.
Likewise the Cylinder HAS-A Circle for its base. Much cleaner. The cylinder delegates some of its actions to its base when it receives a message. Likewise the base (a Circle) delegates some messages to its location (a Point).
Now you have a defensible design, but it might not have used subclassing at all. You get reuse (via delegation) and don't confuse the nature of things and require ad-hoc decision making throughout a long program.