In general, the role of the PO during a sprint should be passive, i.e. provide feedback when asked for it, but not micromanage the work of the team. Any changes that result from such feedback have to be weighed against other priorities. But ultimately, the PO represents those paying for the project and thus calls the shots. As for your specific questions:
- If the PO has detailed expectations about the design, these should be provided as a branding / CI guide before development starts. Demanding lots of detail changes only after seeing the UI in development is not ideal, but if the PO feels these changes are very important and is willing to accept the consequences, i.e. features dropped out of an iteration because people had to implement the desired changes instead, that's OK too.
- Choosing specific elements of the architecture is certainly the domain of the PO, but very much something that should be done before development starts. Fundamental changes later on will cause massive delays (it's pretty much guaranteed you'll have to abort the current Sprint and use at least the next one mainly to implement those changes). Again, if the PO accepts the consequences, it's his decision. If no, it starts to look like the project lacks the main foundation of Scrum: the assumption that everyone is working on a common goal and making rational decisions on how to best get there.
- Again, it's ultimately the PO's decision, and this kind of thing is perfectly OK to discuss with the PO if there are open questions, since he may have domain knowledge your analysts don't have. But if he insists on doing things differently than those who have studied the problem recommend, and without providing a rationale, then that also strongly hints at someone not well fit for the job.
- Whether to implement something as a wizard or a single complex page is a very good example for something the team could ask the PO to make a decision on. But having him give constant feedback on details is not efficient. Basically the idea is to have the team implement a complete usecase and only occasionally get feedback on things they are not sure about or when they have completed a significant piece of work. To get back to your example: after getting the PO's decision, the Team might create a GUI mock-up for the complete wizard or page, show that to the PO to get feedback, change one or two things and implement it, then show the complete implementation in the sprint review.