How to get onboarded quickly at an early-stage startup?

So pre-seed is extremely early, and I'm not surprised with any of the points in your "Context" section. To answer your questions:

For our success (and survival), we need to keep shipping features and products that bring in business. How do I get onboarded quickly so that I can start shipping too?

This depends on what kind of engineer you are, and given that you're senior, it can be either:

• Working on a new codebase - For example, I was hired into Course Hero as their first Android engineer. All of the code I did was from scratch, and it's impossible to "learn the codebase" as I was tasked with creating the Android codebase. In that scenario, I recommend this: "How can I write great code faster?"
• Expanding an existing codebase - In this case, it's more about pattern matching and being super hands-on. This should help: "What is the effective way to understand new repository in order to make the required changes in that repo?"

Also, in an early-stage startup, all learning is manual and captured with institutional knowledge, not anything formal like a wiki. Can you do a single 1-2 hour long pair programming session with whoever your domain expert is to get a deep walk-through and ask all your questions? When Charlie joined us to work on the Taro website, that's what Rahul (the initial maintainer of Taro web) did.

Is there any value in following typical processes and best practices like 1:1s, project planning etc.?

Every company should have 1 on 1 meetings, especially pre-seed startups where deep alignment is so important (if you don't have that, your company will literally die). When Taro was pre-seed and just Rahul and myself, we talked for 45-60 minutes every day. We probably could have made these meetings more efficient, but I still think this was directionally correct.

We gave an entire masterclass about effective 1 on 1 meetings, and I think you can more or less apply all of the advice there: [Masterclass] How To Have Impactful 1 on 1 Meetings

I had the same experience at my workplace. There were no tests, minimal outdated docs, devs with many tasks, etc. Startups are chaotic and the code and processes will reflect that.

I found a sink or swim approach to be best. Find a bug that's being ignored, and work on fixing it. It will force you to bounce around the codebase, get context for business logic, talk to devs that are in the git blame, etc. Plus, you're providing value to the company while you learn.

The silver lining is all these poor processes give you the opportunity to make a massive impact. During onboarding, if you find the dev environment difficult, improve it while you learn to set it up so future devs can benefit. If docs are missing from something you are working on, add them. If you find tests are missing, add them as you learn the codebase. It forces you to solidify your understanding of the business logic and architecture while providing more value.

Ask questions to find out what you need.

Then be sure to document what you learn - ideally create an onboarding guide for whoever joins after you.

Every time you find a bit of friction, like the dev environment, make a small change to improve it. Over time those small changes add up and will help you and the team ship faster.