Fetches a single delivery-attempt row.

Runs the door's list tool once against the named account and returns the first page, annotated per record with the identity admission would de-duplicate on, the value that would move the watermark, what a person would be asked about it, and whether the ledger already holds it. Also returns the exact arguments the tool was called with — for a Gmail door that is the operator's query with the day-granular `after:` term folded in, which is the single most surprising thing about a source. A capped page comes back with `truncated` and `moreAvailable` set, plus the source's own `nextPageToken` when it advertised one — because "50 records, truncated" used to be the end of the conversation, and the answer to "how many are waiting" was therefore "more than 50". Pass `countOnly` for that answer: the same door paged to exhaustion under the same watermark and bound rules, returning `count` — the total, how many the ledger already holds, how many clear the bound, the pages fetched, and which server ceiling stopped the scan (2,000 records / 20 pages) so a floor is never read as a total. No records come back, and `limit` is ignored. Unbounded by default: a caught-up automation returns nothing under its own watermark, and reading that as a broken query is the confusion this exists to end. Pass `applyWatermark` to see what the next scheduled pass would list instead. Read-only in both modes. Nothing is admitted, no cursor moves, and a ledger that does not exist yet is not created. Rate-limited because it drives a live list tool on a button press, and a count drives it repeatedly.`. The list tool runs in an Application — the named trigger's, or the tenant's Default one when none is named — and an account-less door lists that Application's own data, so the caller needs Editor there. A named trigger the caller cannot reach is a 404, worded exactly as one that does not exist.