fix: un dépôt est délivré une fois et retiré, comme en amont

.project/concepts/e2e-harness/ng-e2e-helpers/usage_polyfill-e2e.md

@@ -53,3 +53,7 @@ Everything else the package exports is offered and NOT consumed here — the scr
 **`declareSuite` fits a journey suite and not a check batch.** Only the applicative suite uses it; the other three declare a local `record`/`check` pair and print their own summary, because their shape is a flat list of checks discovered as the run goes rather than named journeys declared up front. The up-front declaration is exactly what makes the report bounded, so this is not a request to relax it — but three of four suites falling outside it suggests the package covers one of two real shapes.
 
 **The screen inventory is exported and unreachable in practice.** `BROKER_SCREENS` and the `WALLET_*` page descriptions are published, but a suite that crosses the broker with `setupBrokerPage` never needs them, and one that wanted to extend the crossing has no supported way to hand a modified inventory back in. As it stands they read as internals that happen to be exported.
+
+## Needs
+
+**A bounded wait for a condition, reporting what it last saw.** These suites hand-roll one in at least three places — polling until `listMyEntityDocs` shows a new document, until an append is visible in this session, until a triple lands — each with its own loop, its own bound and its own failure message. A second consumer, the indexing layer's suite in another repository, independently wrote the same thing to know when a deposit had become an entry. The shape both arrived at is the same: re-READ by ordinary means until a predicate holds, return the first reading that satisfies it, and on expiry name what never arrived **and the last reading seen** — the second half is what turns a timeout into a diagnosis. It is not `within`: that bounds one call, this bounds a convergence. Two independent rediscoveries suggest it belongs on the engagement rather than in each suite.