How do I balance slow code spelunking on my own vs. asking questions to speed things up?

Thanks for sharing such a thoughtful question! I think this discussion should help a lot here: "How do I balance being more independent and asking questions?"

I already ask a lot of questions, and I want to be more self-sufficient because my full-stack team members are pretty busy. (They are all kind and would all be willing to to take some time out of their day.)

I totally get the empathy here, but I feel like you may not be leveraging them enough (and they may actually want to help you more and are waiting for you to ask!).

Of course, there is such a thing as being a bother by asking for too much help. A communication "trick" you can use to get around that is to proactively give them an out. So whenever you ask for help, just tack on a, "No worries if you're too busy to help me, I totally get it! I can go ask someone else 😊", to the end. Another thing I recommend doing is adding a "No rush!" somewhere in there to any ask you have that isn't urgent.

How can I get faster at reading code on my own while balancing a team transition?

Have you tried pair programming? When junior and onboarding engineers in general start out, they're going to have a ton of questions. If you find yourself asking 5+ questions to the same person across a day, it's probably more efficient to just pair program with them for 30 minutes and get all your questions out there in a single burst instead.

While I understand that there is likely no magic threshold to determine the point at one needs to ask for codebase navigation guidance, a good rule of thumb would be helpful when possible.

My rule of thumb is asking a question if you're unable to make any progress on something you're blocked on for 15-30 minutes.

However, I feel like what will help you here is creating a target to work backwards from. In other words, find yourself a coding task and give it a due date. You mentioned that you have a decent high-level understanding of components but are unclear when it comes to the "nitty-gritty". You truly understand the nitty-gritty by actually playing around with the code, but it's easy to do this aimlessly if you don't have a concrete goal. Having a deliverable should fix that.

It doesn't matter if the task is as small as "Change this button from a dark blue to a light blue", just make sure that it has clear success criteria and a date attached. You can ask some collection of managers, tech leads, and whatever other mentors you have on the software engineering side if they have any small tasks they can give you. Series B is somewhat early, but I feel like that's a scale where there's probably a pile of small bugs and tech debt lying around.

Once you have the task, you simply ask questions when you don't think you can complete it on time. You can use decomposition to help figure out when that is.

Best of luck!