I don't have any definite sources for this, but my gut feeling is that the relationship DOES apply to inherited members.
In your example, SportCar "is-a" car, therefor it "has-a" engine.
This could be related to the Liskov Substitution Principle, where a super-type should be replaceable by any of its subtypes. In this case the super-type "has-a" engine, in order for sub-types to follow the LSP they must recognise that they also have an engine.
This should not only follow for members of the class, but for the behavior and state in general - a class should not inherit from another unless it makes sense for every aspect to be inherited. I.e. in your example, if Car had a method "attachBabySeat()", it would not really make sense for SportsCar to inherit from it. Likewise a member protected BabySeat[] babySeats
does not make sense for SportsCar.
The exception to this, in Java, is private
or "package-private" (aka default) member variables. These are generally implementation details that are not part of the abstraction. Subclasses can not access these fields and so I wouldn't consider a private member to be part of the subclass' "has-a" relationship.
In terms of the Java language, when a subclass is created, the superclass is also constructed (either implicitly or explicitly). So when a superclass has a private member, this is still part of the subclass object in terms of memory, JVM etc. For instance, a method on the superclass which uses a private member, can be called from the subclass without problem. So at some level, you could argue that subclasses do "have-a" private field of the superclass, but I'd argue this is at a physical level, not a conceptual one, and can be disregarded.