Do you know of a way to document a significantly-sized application in such a 
    way that it is not massively more efficient to ask a colleague for help than 
    to go source-diving? Say we are talking about a rails app that has been 
    maintained for 5 years and with a reasonably complete test suite.

Yes. You can draw architectural diagrams. You can create a wiki where people document problems and solutions. You can have broader design reviews where people talk about the ways in which they solved various problems and what considerations they took into account when coming up with those solutions. I agree with the other posters in this thread: if you're truly blocked (i.e. literally unable to work) because someone can't respond to your question, there is something deeply wrong with your codebase, or in the way in which your team communicates. Personally, I would expect anyone who's been on the team for more than few months to be largely self-sufficient when it comes to actually coding. Of course, there will be questions when there are multiple possible approaches to solve a given problem, and I would expect someone to raise a flag and ask about the relevant considerations. But in the absence of a reply, you should be able to pick an approach and push forward with it.

    Does a fresh-from-uni or perhaps 2-years-out-of-uni junior developer teach 
    themselves how to ask just enough questions up-front that they don't need to 
    ask more to unblock themselves?

Honestly, at some point, you have to learn your team's codebase. You say that it's massively more efficient for you to ask questions of colleagues than it is to go source diving. That, to me, indicates that you don't actually know your codebase very well. Again, this is a sign of a problem on the team. Either the source is so tangled that no one can hope to understand all of it, or people are becoming siloed - specializing in particular areas of the codebase in ways that leaves them unable to fix problems in other areas. It's all right to be better at one part of the code than another. For example, I'm better at some of the middle-tier/business-logic code than I am at UI work. But, in a pinch, I can jump in and help with UI if it's necessary.

    How does one gain this technical knowledge if you are on a project and need 
    to apply it but don't yet have it yourself?

I'll be honest. It's rough. You have to learn, and you have to realize that outside of university there aren't going to be TAs and professors to point you in the right direction. You will make mistakes. But that's the only way forward. Keep trying. Keep writing code. If you do something and it doesn't work, have a meeting in which you go over what you did, why it didn't work, and what you could have done better.