I have an interview coming up that isn't DSA / System design focused, but rather a project deep dive or work experience deep dive.
If the interview is 45-60min long, how should I best describe my work experience in that given time. Also, if using STAR method to answer work experience / project related questions how many situations per bullet point on resume should be discussed?
It would be good to think about a few problems you have worked through. You want to be able to go really deep on those. Talk through your logic, answer questions about key decisions you made, explain your reasoning, and just be able to go really deep. The more details you can remember and coherently talk through, the better. That is more important than having many stories.
At the same time, you want to be sure your stories cover the likely areas you discuss. You may want to look at what the company is looking for culture-wise and be able to have a story that relates to the big things that they are looking for with their culture and/or the role. For example, is a primary value collaboration or independence? Data-driven or customer-driven decision making? It is good when a story can be adjusted to different qualities so that you have fewer stories.
You really want to be able to go deep on those highly-impactful, highly-technical stories that are relevant to areas they ask (e.g. what was the hardest thing you have ever worked on? what was a time you had someone disagree with you and how did you work through that disagreement?), being ready to answer any questions they ask and drill down into the details.
how many situations per bullet point on resume should be discussed?
There's no correct answer to this question, you'll have to read the interviewer and the situation on the day of.
Hopefully the interviewer will start by sharing how the 45 minutes will be spent (ask about this if not). If they tell you that they want to do a project deep dive for 20 min, then you can be pretty sure that the rest of your resume will be discussed, since there's a lot of extra time.
Reading the body language of the interviewer is also a skill, and asking tentative questions like "I built out component X, I'm happy to share more if that's interesting for you." That way, you can talk about X if the interviewer wants, but avoid wasting time if the interviewer wants to move to other areas.
Adding to what Rahul and David suggested:
It's also good to have a business impact added to the problems/projects you worked on. A problem may be complex but its real value is tied to your business. By talking about how you approached and prioritized the problems to serve the best value for your business a good skill to demonstrate.