Jimbo has an excellent answer but I think there are some things you can do beyond get better and learn.
It's funny that you state that asking the SR dev questions is like 'walking into a Dragon's den'. Documentation is a beast. Software devs, perhaps especially crusty, grumpy, oldschool software devs, often have an extreme allergy to documentation. Often you'll hear the cry "Good code should be self documenting!" But, let's be honest here, if you want anyone else to develop or use your code then you have to have sensible, usable documentation.
Let's also take a moment to point out that any CEO that says things like 'the senior has no time for us two coders' would be, given the rest of your description, a huge red flag for me. Reviewing those flags - the Sr dev has no time for his team, documentation is lacking or incorrect, onboarding was non existent, there's 3 devs all working on completely different projects using an inhouse, undocumented SDK... To be completely honest, if I were in your position I would be job hunting because this sounds like a place where whatever you 'learn' will be some proprietary, inhouse weirdness and that there's little to no chance for career advancement.
That being said, you seem to want to climb mount everest with 2 feet of rope and a bunch of dead weight hanging off of you. So how can you do that?
First thing's first. Documentation is poor to non existent. Pull Request accepted! Whenever you come across something that is undocumented, poorly documented or incorrectly documented - make your own documentation. Share it. It is possible to be an amazing developer and write acceptable documentation. One of the fastest ways to show what you have done, what you have accomplished and be seen as effective is to have documentation you can point to. You're figuring out this nonsense anyway, it takes the space of a few minutes to write down what you figured out. Next time you have that to refer to. Often documenting widgetA can lead to an understanding of how widgetB should/could work. In short documenting helps solidify your understanding of a specific object, gives you more general knowledge to the overall project and begins to put you out there as a domain knowledge expert(as your documentation proliferates and expands.)
As an anecdote for this - my first IT support/weird dev job used a lot of in house tools and had some crazy workarounds and requirements due to the nature of the work. When I started, and throughout my time there, whenever I came across something new I wrote it down. I dumped these in a repo called 'Nahkki's Wiki'. I quit that job 7 years ago, I was back in town meeting with an old coworker who still works there and people who I have never met are still using and expanding 'Nahkki's Wiki'. Every time someone had a question, my name came up because I had documentation around it. A small, cynical part of me things that people trust things that are written down more than things spoken - which meant they listened more when I said "I have a doc for that!" as opposed to "This is why....". In my last Software dev position(in a research lab) and in my current software dev position I've done the same thing. And what do you know, I've been at my current position for 6 months and boom Nahkki is the subject matter expert in the silly, weird in house framework because she wrote all the docs...
What I'm saying here is that writing the docs, though reviled by many people in our field, is a great way to gain knowledge, experience and visibility when you take the time to make it part of your workflow. Anyone can write code, trained monkeys can write code. Not anyone can make code that others can use and extend. Making that code requires appropriate documentation.
Beyond writing the docs as you go(which I really can't emphasize enough) I would challenge your supervisor. If your supervisor says "The SR dev doesn't have time for you" then your response should be a respectful "when I have questions that are blockers how should I proceed?" I would recommend scheduling times to meet and ask questions. You and the other devs are using the same SDK - there should be a regular meeting where you talk about what you are doing now and what blockers you have run into. Never ask a question twice - ask it, understand the response and document it. You should phrase all of this as a blocker to productivity(because it is) and your supervisor should want to make this better.
Frankly, if it were me, I'd be waltzing out of there as soon as possible. Sure you can learn a lot from a crummy situation, but you can learn all that and more from a good or even great situation.