Extract detection into a testable module, fix an over-matching bug

[EnesYilmazcode]

Closes #2.

Why

The detection rules were tangled up with the Gmail glue and chrome.storage
inside one IIFE, so the part most likely to be wrong was also the only part that
could not be run outside Chrome. signatureOnly() and signatureBlock() decide
what gets deleted out of somebody's message, and they had no coverage at all.

What changed

src/detect.js now holds the rules, with no chrome.* and no reliance on
globals beyond the node passed in, so the same file runs inside Gmail and under
jsdom. src/strip.js keeps the observer, the send hooks and the settings. The
manifest loads detect.js first.

promoAnchor() also stopped parsing hrefs by hand and now reads a.hostname
off the DOM, which is both shorter and correct for the two cases in the test at
the bottom of the file.

The bug the tests found

signatureBlock() started at the promo link and climbed while each parent
looked signature-only. When no parent qualified it fell through and returned the
anchor itself, so this:

<div>I have been using <a href="https://mailsuite.com">Mailsuite</a> to track
replies and it works well.</div>

lost its link. The sentence survived, the <a> did not.

The immediate parent now has to be signature-only before anything is removed,
and the function returns null otherwise. That trades a bit of under-matching
for never eating something a person wrote, which is the right way round while
detection is still inferred rather than observed (#1).

Tests

# tests 8
# pass 8
# fail 0

• signature removed, message untouched
• blank line above the signature cleaned up
• tracking beacon survives
• campaign signature with an unsubscribe link left in place, and removed when
  keepUnsubscribe is off
• a link the user wrote themselves is never touched
• a message with no signature comes out byte-identical
• localised signatures (es, de, ja) recognised
• promoAnchor rejects notmailsuite.com and
  example.com/?ref=mailsuite.com

Also adds a GitHub Actions workflow so this runs on every PR.

Still open

Every selector here is still inference. Nothing has been checked against the
real injected markup, which is #1 and needs a sample from a live compose window.

[EnesYilmazcode]

Read this against the case that actually matters, which is not "does the
signature go" but "can this destroy something the user wrote". The new
signatureBlock() guard closes the text version of that hole. There is still an
image-shaped one.

Blocking: signatureOnly() ignores images, so a user's inline image can be deleted

signatureOnly() decides on textContent alone:

let text = el.textContent || '';
...
return text.replace(PUNCTUATION, '') === '';

An <img> contributes no textContent. So this element reads as
signature-only:

<div><img src="cid:screenshot.png">Sender notified by <a href="https://mailsuite.com">Mailsuite</a></div>

The whole block is removed. rescueBeacons() does not save the screenshot,
because it only rescues things that look like tracking pixels, and a real
screenshot correctly fails looksLikeBeacon().

Whether Mailsuite ever wraps its signature around a user image is unknown, which
is exactly the problem. This is the same class of failure the PR just fixed for
text, and it should fail the same way: leave it alone when unsure.

Suggested fix, in signatureOnly() before the text check:

for (const img of el.querySelectorAll('img')) {
  if (!looksLikeBeacon(img)) return false;
}

An element holding a real image is not just a signature, whatever its text says.
Worth a test with an inline image next to the signature.

Non-blocking

rescueBeacons() does root.appendChild(img), which parks the beacon at the
very end of the compose body. If the signature was not last, the pixel jumps
past whatever followed it. Invisible either way, so cosmetic, but
block.parentNode.insertBefore(img, block) keeps it where it was for the same
effort.

settings.removed counts scrub passes rather than distinct signatures. The
observer can fire more than once on the same compose window, so the number in
the popup drifts high. Fine as a "this is working" indicator, which is all it
claims to be, but it should not be read as a real count.

No test covers the climb in signatureBlock(). Every fixture here has the
signature exactly one level deep, so the while loop never runs more than once.
A nested <div><div>…signature…</div></div> fixture would pin the behaviour the
loop exists for.

Otherwise

Moving promoAnchor() onto a.hostname is the right call, and the two
rejection cases in the last test (notmailsuite.com, and mailsuite.com
appearing only in a query string) are the ones a hand-rolled string check would
have got wrong.

[EnesYilmazcode]

Pushed b122b11. All three addressed.

The image hole. Fixed as suggested, signatureOnly() now bails on any
non-beacon <img> before it looks at text at all. Test added with an 800x600
cid: image sitting next to the signature: block count 0, image intact.

Beacon position. Now parent.insertBefore(img, block).

That one had a tail. rescueBeacons() ran before trimBefore(), so the pixel
landed between the block and the blank line above it, previousSibling became
an IMG, and trimBefore() stopped on the first iteration. Moving the beacon
fixed the cosmetic problem and quietly broke the blank-line cleanup. The two are
swapped in scrubRoot() now, with a comment saying why the order matters, and
the new test asserts both properties at once so they cannot drift apart again.

Worth noting this only surfaced because a test already pinned the blank-line
behaviour. Without it the fix would have looked clean.

Climb coverage. Added a nested .outer > .inner fixture. Every previous
fixture was one level deep, so the while loop had never actually run.

Not doing in this PR:

• settings.removed drifting high. It is a "this is working" indicator and the
  popup labels it as a count, which is a small honesty problem, not a
  correctness one. Filed separately if it bothers anyone.
• Everything about real markup is still Detection is inferred, not observed: capture the real injected signature markup #1.

11 tests, all green.