The other thing I usually want and make is a complete ERD or complete ERD of the teams specific area and connections to other areas. Knowing the logically-unique keys for every table and effective FK relationships and cardinalities can tell you a whole lot very quickly and accurately.
Learn terminology and conceptualization (both technical and product-customer focused ones) to put everything above and more into context.
Get assigned to an ongoing or new project (or mini-project), fixing bugs is a fantastic way. Allows for deep-dives that cover depth through layers of the system and learn to navigate the codebase and logs, stats, what questions to ask.
Start understanding performance or scaling issues, either already identified or be able to discover them by accessing stats or error/slow query logs, etc.
Understanding the codebase is low on my list of priorities and approached tactically. For a specific given task, learn as much as I need to know and not too much more. Slowly and organically learn the typically undocumented architecture details, again on a need-to-know basis. All these things become higher priority later.
The next important goal might be getting to know the people, their views. Ask a lot of questions. Don't try to seem smart - ask all the dumb question at the beginning. It gets harder to ask them the longer you are on the job.
Salaries, benefits, titles, etc aren't invested in unless the need is real, and real needs take time to solve. The first month is familiarizing yourself with the problem you need to solve, and the culture of the organization.