There are a few questions to unpack in there.
First, when to start testing in a 2-week sprint: as soon as possible. Many experienced Scrum teams focus on getting one or two backlog items to a testable state before moving on to others so that testers can get working on those. This creates a better flow of work through testing so that it doesn't all pile up at the end.
Or, Testing first: There are even techniques like Test-Driven Development and Behavior-Driven development where you write failing tests before writing any code. This requires developers, testers, PO, and stakeholders to work very closely together and integrates the two activities continuously. In both of these cases, you take it one test case at a time, develop to that test case, then move to the next one. TDD is focused at the code level and is driven with unit tests and the average cycle of testing and development is usually measured in minutes. BDD is higher-level and probably more like the testing you are thinking of, but even with these the full cycle to define and resolve each test case is rarely greater than a few hours.
As for automated vs manual, my best experiences have been to treat the approach to them the same. I can define a test scenario and then if it's something I'll want to test repeatedly, automate it in the development process. Otherwise, leave it manual. For most teams, this opens up more options for test automation. When a QA engineer has to automate a test after the fact, they are often stuck doing automated black-box testing. When you automate during development, the developer can help create hooks into different levels of the code, testing behavior very close to its source instead of having to test it from three levels away, leading to more effective and less fragile tests.
Finally, I'm curious about the PO approval. High level test-cases are often closely related to acceptance criteria. In fact, there is a practice called Spec by Example where the two are the same thing. I would expect any of these types of test cases to be defined and agreed upon before the backlog item was brought into a sprint. That's not to say some things won't come up in exploratory testing, but I'm used to seeing those result in quick hallway conversations with the PO, not a formal process. On the other hand, tests tied to the implementation itself are often the purview of the team, not the product owner.