Add Synology to the OAuth compatibility list (needs one vendor link)

`data/devices.json` records, for each vendor, whether their hardware can do OAuth 2.0 once Microsoft 365 stops accepting Basic authentication for SMTP AUTH at the end of December 2026. It has 17 entries. **Synology is not one of them**, and Synology NAS notification and MailPlus settings are in a very large number of offices. That gap is the whole task. ## What to send One entry, in the shape the file already uses: ```json { "vendor": "Synology", "product": "NAS notification and MailPlus settings", "status": "check-advisory", "models": ["the models the statement actually names"], "evidence": "https://link-to-the-published-synology-statement", "notes": "What breaks, which flow is supported, and which models are not promised anything." } ``` `status` is one of: `available`, `partial`, `check-advisory`, `unsupported`, `none-planned`. ## The one rule that matters **Every entry must carry an `evidence` URL pointing at something Synology published.** A support page, a firmware release note, a KB article, a PDF. Not a forum post, not "my printer does this", not a guess. If Synology has published nothing, that is a real and useful answer — say so in the issue and we will not invent an entry. A wrong row here sends an administrator to buy hardware they did not need, or to skip a migration they did need. The two entries merged this week are worth copying as examples. The HP one is the better model: it used `partial` and then **named the LaserJet Pro models that do not support OAuth**, which is worth more to a reader than the list of models that do. ## Where it goes Edit `data/devices.json` only. The table in `docs/DEVICE-COMPATIBILITY.md` and the page under `docs/devices/` are **generated** from it and checked in CI, so the two cannot drift — do not edit them by hand, they will be overwritten. Run this before opening the pull request: ```bash python tools/build-device-table.py ``` ## Two things about how this repository treats you Your first pull request will show its checks as pending until a maintainer approves the workflow run. That is a GitHub default for first-time contributors, not a judgement on your change, and there is now a job watching that queue so it does not sit unnoticed. If the checks come back red on something that looks unrelated to your change, say so in the thread before you start debugging it. That happened to the last contributor and the cause was our bug, not theirs. Comment before you start so two people do not research the same vendor.