Detect the signature by Mailsuite's own markers, fix a partial-deletion bug

[EnesYilmazcode]

Closes #1.

Read gmail.end.bundle.js out of the installed extension, 12.87.0. The answer
to #1 turns out to be that there was never anything to infer: Mailsuite labels
its own signature.

What it actually renders

All seven templates in the bundle share a wrapper:

<div id="mt-signature" contenteditable="false" g_editable="false">
  <table border="0" cellpadding="8" cellspacing="0"
         data-signature-template="senderNotified" data-signature-version="17">

data-signature-template appears 8 times, always senderNotified. The id comes
from a single constant, tC = "mt-signature", used by all 7 builders. So
detection is now a selector:

#mt-signature, [data-signature-template],
[class*="mt-signature"], [class*="mt-old-signature"]

Outermost match only, since mt-signature-logo is a child and matches the same
selector. The promo-link heuristic stays as a fallback for markup with no
marker.

The bug this fixes

The extension was worse than useless against real mail, and the tests said it
was fine because every fixture was written from the same guesses as the code.

The real signature contains a 24x20 logo from
s3.amazonaws.com/mailtrack-signature/logo-grey.png. The image guard added in
#4 treats any non-beacon image as evidence the block belongs to the user. So the
climb stopped at the row holding the logo, deleted the inner cell, and left the
wrapper, the table and the logo sitting in the message.

Measured against real markup before the fix:

logo img present: false  -> removed: 1 | signature gone: true
logo img present: true   -> removed: 1 | signature gone: false

A returned count of 1 with the signature still on screen. Partial deletion is a
worse outcome than doing nothing, and the counter in the popup would have
cheerfully claimed success.

The guard was right for the fallback and wrong for the marked path. A marked
block is Mailsuite's by their own admission, so the image inside it is theirs
too. The guard now applies only to the heuristic, where the over-matching risk
actually lives.

Also confirmed from the bundle

• Beacon format: https://(sub.)?(mailtrack|mailsuite).<tld>/trace/mail/<40 hex>.png,
  matching what looksLikeBeacon() already rescued.
• Signature logos come from s3.amazonaws.com/mailtrack-signature/, a different
  host, so they are correctly not mistaken for beacons and go with the block.
• mt-old-signature exists as a legacy variant, now covered.
• There is an mt-remove-signature control rendered inside the signature
  itself, which is more evidence for Prefer Mailsuite's own opt-out over deleting DOM #3.

Tests

15, up from 11. Six new, from transcribed real markup:

• every live signature version (12, 13, 15, 16, 17, 18) removed whole
• their logo goes, a user's cid: image beside it stays
• a beacon inside the block survives it
• markedBlocks() returns outermost only

Still not verified

Nobody has loaded this into Chrome against live Gmail. The compose-body and
Send-button selectors remain inference. The signature itself is now settled.