Project Plan/Timeline

You've mentioned "project" several times and "product" not once. What does that tell you, as a Scrum Master? Bear in mind that a Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide.

felt the project requirements document was out of date and there was no clear understanding of what was done so far

Sound like an ideal candidate for Scrum to start an iterative and incremental to deliver value and start gaining empiric evidence.

planning a project over multiple sprints and mapping its progress

This come dangerously close to instead of having one big waterfall project, using Fake Scrum to cut it down into multiple smaller waterfall projects, ergo, not doing scrum at all.

wouldn’t that be on the PO to update/know those types of things?

Using the Scrum Guide, what responsibilities are stated for the Scrum Master and the PO? Try to list them here, so you can maybe state your own answer ;)

It's a great question and here's my take. I'm assuming there is at least one Scrum team.

"When talking timelines/planning on a specific project, who owns that?"

Everyone (not just the PO or the Dev Team).

The reason being everyone who's invovled in deliverying the outcome has to own the project. You may have a project manager that is keeping things in check but they don't own it; it has to be agreed with by all doing it.

"there was no clear understanding of what was done so far."

I'm hoping there are plans for what could go into a release and what functionality that enables. If the work has not been divided into increments then something to look at. Scrum only has three things that shows stuff: product backlog, sprint backlog, and increment. The increment development should show what has been done. This should show what's done and maybe done.

"planning a project over multiple sprints and mapping its progress would be on me."

I have no problem and encourage teams to plans over time. The SM role in this is not help the Scrum team and business do this not take it on as Scrum/Agile Project Manager. The team should be planning at different levels to highlight the approach and the risks with that approach.

" If the PO provides the work goal for the sprint and its understood what work the dev team has brought in and completed each sprint, wouldn’t that be on the PO to update/know those types of things?"

The PO should bring the Sprint objective after reflection on how things are going based on evidence. So the PO should know how work is developing but it's a team decision. The PO has been given authority to make decisions on behalf of other people and those people shouldn't be surprised on progress as everyone owns the project.

As I see it, the accountability of information about the state of the product sits with the PO. But Scrum is not a straight jacket/cookbook that forces person X to do task Y, it is a framework that helps you shape your way of working for optimal value delivery.

So I'm saying that the accountability means that the PO is likely the one who will first notice that there may be something missing there.

If I may suggest a way to think about this: start by looking at what the problem means in terms of risks to value delivery. To me, it sounds like a textbook problem for one of the three Scrum Pillars, and with that, it is a problem for the Scrum Team. With that in mind, it would be a great discussion subject for a retrospective that really hits one of the core aspects of what it means to be a Scrum team.

To me, much more interesting than the question who is responsible for updating which documents \o/

I do this a lot and will do it again. Pulling some statements from the Scrum Guide that play into my interpretations. 

From the Scrum Guide section on the Sprint Review (emphasis added by me). 

The Sprint Review includes the following elements:

• Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
• The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done";
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
• The Development Team demonstrates the work that it has "Done" and answers questions about the Increment;
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
• Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
• Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

To your question

After the meeting she mentioned that planning a project over multiple sprints and mapping its progress would be on me... wouldn’t that be on the PO to update/know those types of things?

I interpret the emphasized statements to answer your question with it is the entire Scrum Team's responsibility to convey progress and provide insight into what has been completed.  This is done with the stakeholders which could include a Project Manager.  

and felt the project requirements document was out of date and there was no clear understanding of what was done so far.

If you are doing Scrum and agile correctly I would fully expect that the requirements document created before work began would become out of date.  If Scrum is done correctly the requirements by which you work are identified at the end of every Sprint. If you are actually including your stakeholders in your Sprint Reviews it should be very obvious to them what requirements are driving the current work and what has been done. They will be in control of what work is done and how much of it occurs.  The original requirements are based on what is needed at the time they were written.  But in today's fast paced world, what you want built today is most likely not what you will want in 6 weeks. Agile is meant to allow you to react to change quickly not to build something described in a 20 (or even 2) page document written at point in time no matter how long it takes you to build that exact set of requirements. 

Since you are a new Scrum Master I encourage you to read the Scrum Guide. It isn't that long but it is what you are responsible for helping the organization to understand and appreciate. From the Scrum Guide section on the Scrum Master where the Scrum Master's responsibilities to the organization are listed(again I added the emphasis). 

• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

Good luck on your Scrum Master journey.  Please come back often to these forums because there are a lot of good opinions and advice given here.  

I had a manager before who kept on insisting that I should manage or set a limitation to the requirements for the MVP provided by the PO every sprint planning. I told him that in Scrum, it would be better if I should just remind her (the PO) of what will be the impact if she prioritized req X over Y. But in the end, the PO should have the final say with the requirements.

But my ex-manager kept on insisting...