Close out #3 and #5, add a system diagram

[EnesYilmazcode]

Closes #3. Closes #5. Partially addresses #7.

Two of the three open issues turned out to be answerable by reading
gmail.end.bundle.js rather than by writing code.

#3, drive their opt-out instead of deleting the node?

No, and the bundle says why. Their Remove handler kA() branches on
signatureVirality, which is the signature variant the server assigned the
account:

var a = iK(o).signatureVirality;
kI = [17, 18];
kI.includes(a)
  ? (new x7(function () {          // dialog, and on confirm:
      kT(false);                   // POST /settings/update/signature
      iP(sP({ signature: false })); //      { signatureEnabled: false }
      aM(t, hg);                   // remove the node
    }), kP(n, true))
  : iV(o).disableSignature || kC(); // otherwise: upgrade modal

So:

variant	what Remove does
17, 18	dialog, then persists server side. permanent.
11 to 16	this email only, plus the upgrade modal unless the account has disableSignature

Three reasons not to build on it:

1. It is only a real opt-out on two of the eight variants, and the variant is
   not ours to choose.
2. On the rest it can fire the upgrade modal on every send.
3. The persisting path is a server call that changes an account setting. An
   extension quietly flipping that on somebody's Mailsuite account is a much
   larger action than deleting a node out of a draft, and a much ruder surprise
   if they did not expect it. Local deletion stops the moment you switch the
   extension off. A flipped account setting does not.

The useful half of this is now in the README, including how to check your own
variant:

document.querySelector('[data-signature-version]')

Anyone on 17 or 18 should click Remove once and uninstall this extension.
Saying so in our own README costs nothing and is true.

#5, the popup counter

It counts scrub passes, not distinct emails, because the observer can fire more
than once on the same draft. Relabelled with the caveat instead of faking a
precision nobody needs:

0 removals
Counts scrub passes, not distinct emails, so one stubborn draft can score more
than once.

Took the cheap option from the issue deliberately. A wrong label is worth fixing;
threading per-compose-window state through the extension to make the number
exact is not, for something nobody audits.

#7, screenshots

Still open, and I cannot close it. Real before and after shots need a browser, a
Gmail session and a live Mailsuite account.

What I could do is docs/how-it-works.svg, which carries the two things the
ASCII was straining to show: the tracker-versus-watermark split inside the
email, and the five-step loop that produces the read receipt, with the watermark
visibly absent from it. The README embeds it and two ASCII blocks came out.

Deliberately not faking it: rendering their signature markup standalone and
presenting it as a Gmail screenshot would look better and be a lie.

Tests

15, unchanged, passing. Nothing in this PR touches detect.js.