orders: bring the lifecycle-only toggle's numbers up to date (board 210)

The count moved three times on 2026-08-12 and the history is the point:

  755  when the predicate was written
  904  after board 219 turned unstated zeros into NULLs — those 149 rows had
       been failing the "no amount" test on a technicality
  699  after 210a retired 205 Amazon "share your experience" mails, which were
       never lifecycle events at all
  620  after 210b joined 79 phantoms to their real parent, placebo-verified at
       a 1.9% error rate

What is left is the corpus coverage ceiling rather than a defect — a mail whose
parent is not in the corpus has nothing to join to — and the tooltip now says
that instead of describing the whole class as an open ingestion defect.

src/app/orders/page.tsx

@@ -526,7 +526,7 @@ function OrdersContent() {
           ))}
         </select>
         <label className="flex items-center gap-2 text-xs text-zinc-400 cursor-pointer select-none"
-               title="Rows with no amount, no order reference and one lifecycle event are not purchases — they are a second entity minted from a mail describing an order that already exists. Hiding them is a workaround for a known ingestion defect, not a fix.">
+               title="Rows with no amount, no order reference and one lifecycle event are not purchases — they are a second entity minted from a mail describing an order that already exists. 620 remain: the review-request mails have been retired and the ones whose parent could be identified have been joined to it, so what is left is mail whose parent is not in the corpus.">
           <input
             type="checkbox"
             checked={showLifecycle}

src/lib/order-feed.ts

@@ -108,14 +108,22 @@ export interface OrderFilters {
 /**
  * Rows with no amount, no order reference and a single lifecycle event are not
  * purchases — they are a second entity minted from a mail describing an order
- * that already exists (Amazon "share your experience", DoorDash no-contact
+ * that already exists (DoorDash no-contact delivery details, shipment notices).
- * delivery details, shipment notices). 904 of them as of 2026-08-12.
+ * 620 of them as of 2026-08-12.
  *
- * It hid 755 when written. Board 219's zero-to-null repair took it to 904:
+ * The count moved three times that day and the history is the point:
- * those 149 rows had been failing the "no amount" test on a technicality — an
+ *   755  when this predicate was written
- * unstated 0 they should never have carried — and they match the phantom
+ *   904  after board 219 turned unstated zeros into NULLs — those 149 rows had
- * signature on every other count, so hiding them is the predicate working, not
+ *        been failing the "no amount" test on a technicality
- * collateral damage.
+ *   699  after board 210a retired 205 Amazon "share your experience" mails,
+ *        which were never lifecycle events at all (ingest/order_noise.py)
+ *   620  after board 210b joined 79 phantoms to their real parent
+ *        (jobs/phantom_order_joiner.py, placebo-verified at a 1.9% error rate)
+ *
+ * What is left is the corpus coverage ceiling rather than a defect: a mail
+ * whose parent is not in the corpus, or whose merchant is ambiguous, has
+ * nothing to join to. This stays a UI workaround for those, and the toggle
+ * still says so.
  *
  * This is a WORKAROUND for board 210, not a fix. The upstream defect is that a
  * lifecycle mail printing no order reference cannot join its own order, so it