Challenge 2: A Sealed Vehicle Hierarchy With Exhaustive switch — Possible Solution
====================================================================

VehicleDemo.java:

public class VehicleDemo {
    sealed interface Vehicle permits Car, Motorcycle {}
    record Car(String model) implements Vehicle {}
    record Motorcycle(String model) implements Vehicle {}

    static int wheelCount(Vehicle v) {
        return switch (v) {
            case Car c -> 4;
            case Motorcycle m -> 2;
            // no default branch written
        };
    }

    public static void main(String[] args) {
        System.out.println(wheelCount(new Car("Sedan")));
        System.out.println(wheelCount(new Motorcycle("Cruiser")));
    }
}

Output:

    4
    2

Explanation:
Vehicle is sealed and permits exactly Car and Motorcycle -- no other
type can ever implement it, anywhere, in any file. Because the
compiler knows this closed set completely, it can verify that the
switch's two case branches genuinely cover every possible Vehicle
subtype, so no default is required at all.

If a case were omitted -- say, the Motorcycle branch were deleted --
the compiler would reject the switch expression outright with an
error stating the switch is not exhaustive, because it can prove
statically that a Motorcycle value could reach the switch with no
matching branch to handle it. This is only possible because Vehicle
is sealed; an ordinary, unsealed interface could gain new
implementations from anywhere, so the compiler could never prove
exhaustiveness for it and would require a default branch instead.

WHY THIS WORKS AS AN ANSWER
------------------------------
This builds the exact sealed-interface-plus-exhaustive-switch pattern
the chapter introduces, with no default branch present, and the
explanation correctly ties exhaustiveness checking to the sealed
type's own closed, compiler-known set of permitted subtypes.