Thanks for clarifying.
It may depend upon the query plan.
The one I see when I run this matches to both of the end nodes first, and then performs a VarLengthExpand(Into) operation, meaning that the filtering of the end nodes is performed within the operation, since it already found both of them. It does not need to separate the var length expand and filter steps into two separate ones. That said, even if the result is going to show a row count for after that filtering, the db hits should reflect the work that was done in expansion and node id comparison.
If the plan or query was different, then you might see a VarLengthExpand operation coming only from one side, and that's where all of the supernode's relationships would be considered, and then it might be followed by a filter operator on the property name, which would bring the rows down to the exact matches.
So theres no real "magic" here, all relationships of the supernode DO have to be expanded and filtered in some way. The VarLengthExpand(Into) operator just takes care of that filtering for you instead of needing to do the filtering in a separate operator, so you don't see the rows being expanded or filtered in the plan, though you should see the db hits from it.