Set Up Site Contact-Form Email

Sets up a CONTACT FORM → EMAIL relay for the user's hosted (static) site using the user's OWN Gmail or Yandex — with NO third-party dashboard: the user configures everything here, in chat. A static page can't speak SMTP itself, so its form POSTs to our thin relay and we forward the message through the user's own Gmail/Yandex (Gmail/Yandex does the actual sending). The site OWNER sets BOTH the sender (from_email) and recipient (to_email); the visitor filling the form cannot change them, so it cannot be abused as an open relay. provider: 'yandex' (smtp.yandex.com:465) | 'gmail' (smtp.gmail.com:465; requires a Google APP PASSWORD, not the normal password) | 'other' (smtp_host + smtp_port). from_email must be the SMTP account (or a verified alias), otherwise Gmail/Yandex rejects the send. By default sends a TEST email to to_email to verify the credentials and reports the result. Returns the form endpoint URL + a ready-to-paste HTML <form> snippet (with honeypot). Re-running reconfigures the same server's form. The SMTP password is stored encrypted; only the site owner's fixed to_email ever receives mail.

READ-ONLY STATUS: call with only `server` (no smtp_user / smtp_pass / to_email) to see whether that site's form is already set up, its endpoint URL and the field contract, without entering any password. A new site has no endpoint yet — it is created on the first real setup, so build the form with the action in one place and fill it in after setup.

Field contract of the endpoint: POST as a normal HTML form (form-urlencoded or multipart; JSON is not read). Every field whose name does not start with "_" is forwarded in the e-mail; `email` becomes Reply-To, `subject` sets the subject line. `_gotcha` is the hidden honeypot (filled = silently dropped). `_redirect` = an absolute https URL to send the visitor to after sending, with ?sent=1 or ?sent=0 appended; without it a small thank-you page is shown (HTTP 200, 502 if the mail account refused). No CORS headers are sent, so use a plain form submit (or fetch with mode:"no-cors", where the reply cannot be read). Limit: 20 submissions per hour per form (HTTP 429); a GET on the endpoint answers 404/405 by design. The endpoint lives on the platform domain, NOT on the site's own origin: there is no `/_opus/form` or similar path on the site, so point the form at the endpoint this tool returns. It replies with an HTML page, never JSON, so a script cannot read `{ok:true}` from it.

ONE FORM PER SERVER: the relay is keyed by `server`, so every site hosted on the same server shares the same endpoint, sender and recipient. Re-running for that server changes it for all of them.

PASSWORD WITHOUT THE CHAT: with smtp_pass empty, the app password is typed on a secure setup page instead of in the conversation. With smtp_user, from_email and to_email but WITHOUT smtp_pass, the reply carries a `setup_url` (valid for 1 hour) where the user types the password on our own page; the SMTP test and setup run there. Afterwards call with only `server` to read the endpoint.