It’s a challenging topic. Especially if you have a distributed team with team members in different geographic areas and time zones.
If you prepare designs too far in advance, there’s a high probability that the feature will evolve and change. The designs you make are outdated by the time the developers get there. And all you’re doing is creating waste.
If you’re designing too close to a sprint (e.g. in the week before it will be implemented), there is a high risk that the designer and UX questions show what’s missing in the user story. This starts discussions with the product owner and other stakeholders. In my experience, it’s the wireframes and the screens that trigger more and deeper responses and discussions from product owners and project leaders, compared to their own written business requirements.
In general, the UX discussion gets very difficult if there is not enough information on the end-user and how they will use the app; no direct access to real clients for questions and surveys.
Design screens early on, ideally in the sprint before a function is developed
After a couple of sprints (still in the newbie category), I recommend following the advice given in option 2: Start as early as possible working on your web app design and UI vision. Things like what kind of grid, what basic layout do you want to follow, and what the header and footer, as well as the basic navigation should look like. Design some of the main screens. At the same time, expect that interaction and design changes will occur.