docs(waitlist): make the AGE-100 after-number a grep, not an inbox crawl (#168)

* docs(waitlist): make the AGE-100 after-number a grep, not an inbox crawl

The doc told a future reader to split recovered mailto signups "by the App:
line", which in practice meant opening Chatwoot conversations one by one and
eyeballing bodies — slow, and easy to get wrong in the direction that matters
(missing a stamped mail reads as "clean").

The reconciler now does the split itself
(VibeBrowserProductPage#237) and prints it:

  scanned=N synced=N skipped=N failed=N unstamped=N stamped=N builds=vX:N

Document that line as the read, with the exact gh commands, and state the pass
condition explicitly: stamped must be 0, because stamped>0 means a build that
carries the AGE-87 retry queue still fell through to mailto.

Refs AGE-100.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

* docs(waitlist): record the first post-release reading of the build split

Proof the measurement pipeline works against the real inbox, not just a stub:
the first reconciler run carrying the split (2026-08-14 09:57 UTC) printed

  scanned=34 synced=0 skipped=34 failed=0 unstamped=0 stamped=0

— the same 34 known conversations as the pre-release baseline. Labelled as one
hour of exposure rather than a verdict, so nobody mistakes it for the week-out
number that actually closes AGE-100.

Refs AGE-100.

Co-Authored-By: Paperclip <noreply@paperclip.ing>

---------

Co-authored-by: engineer <engineer@macbookpro.lan>
Co-authored-by: Paperclip <noreply@paperclip.ing>

distribution/waitlist-signup-path-coverage.md

@@ -55,6 +55,48 @@ into the mail (`buildWaitlistMailtoUrl`, `src/lib/waitlist.ts`). That gives a cl
 | no `App:` line | a build older than v0.4.13 — expected, this is the ~436-device sideload cohort no release can reach |
 | `App: OpenCode Mobile v0.4.13` or newer | a current build still reached mailto — the retry queue leaked, **file it as a new defect with the mail as evidence** |
 
+### Reading the after-number
+
+Do **not** open Chatwoot conversations by hand — the reconciler does the split itself as of
+[VibeBrowserProductPage#237](https://github.com/dzianisv/VibeBrowserProductPage/pull/237). Every
+hourly run now prints one grep-able line:
+
+```
+scanned=N synced=N skipped=N failed=N unstamped=N stamped=N builds=v0.4.13:N
+```
+
+- `unstamped` — recovered signups from builds older than v0.4.13. **Expected**; this is the cohort
+  no shipped code can reach, and it is the number that should account for essentially all of
+  `synced`.
+- `stamped` — recovered signups from builds that carry the AGE-87 retry queue and fell back
+  anyway. **This must be 0.** Anything above 0 is a live defect, and the reconciler already says so
+  in its alert issue and in the Chatwoot internal note, naming the exact conversations.
+
+So the week-out read is:
+
+```bash
+gh run list --repo dzianisv/VibeBrowserProductPage \
+  --workflow "Waitlist Mailto Reconcile" --limit 200 \
+  --json databaseId,createdAt,conclusion
+# then, per run id:
+gh run view --repo dzianisv/VibeBrowserProductPage <id> --log | grep -E "^scanned="
+```
+
+Sum `stamped` across the week. `stamped=0` closes AGE-100 with the number; `stamped>0` opens a
+defect with those conversations as evidence.
+
+First reading after the release, from the run that first carried the split
+([run 31790218194](https://github.com/dzianisv/VibeBrowserProductPage/actions/runs/31790218194),
+2026-08-14 09:57 UTC, against the real inbox):
+
+```
+scanned=34 synced=0 skipped=34 failed=0 unstamped=0 stamped=0
+```
+
+Same 34 known conversations as the pre-release baseline, nothing new. That is one hour of exposure,
+not a verdict — it only proves the measurement pipeline reports the split end to end. The week-out
+sum is what closes AGE-100.
+
 ## Method / reproducing
 
 ```bash