Indeed protected methods can be useful for this. Depending on the task at hand, I find it can be useful to separate code into it's own namespace (one way or another) to make it more clear what the user-facing code does.
Regardless, as you noted, my point is to not prevent access but rather make it obvious if you're using implementation details.
Most test frameworks are very un-opinionated, and perhaps that is a mistake.
Framework doesn't care if half your unit tests are functional tests, if you slide E2E test code into the before*() call in an integration test. If your white box and black box tests are snuggled up to each other in the same test suite. If your tests only pass if they run sequentially, in this particular order.
It's no wonder we can't get the terminology straight. You can be years into writing tests before anyone or anything calls you out.
Regardless, as you noted, my point is to not prevent access but rather make it obvious if you're using implementation details.