It's an single integration test.
First of all it has nothing to do with playwright, it's common automation scenario which can occur while using any automation library/frameworks. I have faced this similar scenario in qtp, selenium, protractor, and playwright .
Usually this will be an single integration test where we dynamically store ID on a
test level ...
One test. Two setup steps.
What you have described is very common, particularly as test scenarios get more complex.
What you need is one test with setup that does the user logging in, the user selecting the item (save the id) and then deleted and then you go the dashboard.
So don't think in terms of your two existing tests, think in terms of a new test but ...
I think there are two parts to this.
Write self-executing, living documentation through using BDD code as @kirbycope indicates.
Figure out a way to educate non-technical folks that 100% coverage never happens at a functional level (don't call it an 'education' of course, call it an opportunity for a deeper conversation about value or some such bs). 100 ...
I use the "living documentation" and clear language of Cucumber. The Sceanrio Outlines will show what data is being as input. You can give everyone Read access to the repo (works for my smaller clients) or write a script to pull it into a spreadsheet (works for my government clients).
Scenario Outline: eating
Given there are <start> ...