docs: add Synology OAuth compatibility - #252

All three merged — Sharp, Toshiba and Synology. With HP and Lexmark earlier
that is five vendors from you in two days, and the compatibility list has
gone from 15 entries to 20.

Two things you did that are worth naming, because they are the difference
between a row that can be cited and one that cannot:

Every entry has a first-party source. Sharp's own manual, Toshiba Tec's
own notice, Synology's DSM 7 documentation. Not a forum, not a reseller blog.
That is the only rule this file cannot bend on, and you have not needed to be
told it once.

You used check-advisory where the vendor was conditional. Toshiba and
Synology are not clean "supported" answers and you did not round them up.
An optimistic row costs somebody a day before they find out.

Three of them conflicted on data/devices.json because the file moved under
you while you were working — my changes, not yours. I resolved and pushed to
your branches rather than asking you to rebase three times.

If you want more, the open ones are Epson (#210, claimed by @iharshlalakiya)
and then genuinely uncharted ground: device panel codes. What a printer
actually displays when SMTP auth fails — Kyocera shows 1102, which looks like
a hardware fault and is not one. We have documented exactly one, and a
technician searching that code finds nothing that connects it to a mail server.
Same rule: a vendor page, or say you could not find one.

Thanks for the detailed feedback — I really appreciate it.

I’ve enjoyed contributing to the compatibility work, but I’m also looking to get more involved on the engineering side of the project. If there are any open coding issues, bugs, tests, tooling improvements, or small backend/frontend tasks where an outside contributor could help, I’d be happy to take one on.

I’d especially appreciate a chance to contribute beyond the device-data work if there’s something suitable for a first coding contribution to ZeroSMTP.
@msgwing

@Mohitingale13 — this sat for two days and it should not have. Sorry.

Yes, and there is real work rather than something invented to have an answer:
#293 — a test suite for zerosmtp-check.

The package has no tests at all. scripts in its package.json is empty, and
CI runs three smoke checks written inline in the workflow: --help, a bad
hostname, and --json. Those prove the program starts. They prove nothing
about whether it answers correctly.

The part worth testing is pure, so no network and no SMTP server are needed:
errors.js exports the error table and the per-vendor panel codes, and
--explain matches pasted text against them.

There is a specific reason this matters here. That matching logic broke silently
once already: a \b in the panel-code regular expression became a literal
backspace character. The code still looked right in the editor and in the diff,
nothing threw, and the lookup simply stopped finding anything. One test over
one known panel code would have failed immediately.

The issue names what to cover and what "done" looks like, including the part I
care about most: deliberately break the regex and confirm the test fails. A
guard nobody has watched fail is not a guard.

Node 22 is what CI uses, so node:test is available and no new dependency is
needed.

On the five compatibility entries you already landed — Lexmark, HP, Sharp,
Toshiba, Synology — those are not filler. They are five vendors an administrator
can now check before December instead of finding out when scan-to-email stops.
The device table went from 15 rows to 20 largely because of you.

Take #293 if it appeals. If you would rather something else, say what kind of
work interests you and I will find the honest version of it rather than inventing
a task.