feat: Move mail system to shared

claude.md

@@ -61,7 +61,7 @@ vantage/
 │       ├── grpc/                    # gRPC server + generated pb
 │       ├── models/                  # MongoDB documents
 │       ├── monitorsched/            # server-side monitor scheduler
-│       ├── notify/                  # smtp, http, templating, dispatch
+│       ├── notify/                  # channel dispatch: http, discord, slack, telegram, smtp
 │       └── services/                # business logic + migrations
 ├── web/                             # the application UI (authenticated)
 │   ├── app/(app)/                   # authed routes
@@ -77,7 +77,6 @@ vantage/
 │   ├── cmd/main.go
 │   └── internal/
 │       ├── api/                     # contact
-│       ├── mail/                    # SMTP
 │       └── store/                   # Mongo connect helper
 ├── admin/                           # licensing authority: the only signer
 │   ├── cmd/main.go                  # boot: two Mongo connections, reconciler, HTTP
@@ -88,7 +87,7 @@ vantage/
 │       ├── inject/                  # licence write path into the control plane
 │       ├── cloudprov/               # instance write path: creates instances + owners
 │       ├── licensing/               # Issue, LinkInstance, Relink
-│       ├── mail/                    # verification and licence delivery
+│       ├── mail/                    # admin's boot-time shared/mail Sender
 │       └── models/                  # accounts, instances, licences, plans
 ├── adminsite/                       # staff + customer console (vantage-hq)
 │   ├── app/(customer)/              # overview, instance, link, billing
@@ -96,6 +95,7 @@ vantage/
 │   ├── components/                  # AppBar, PageHeader, PageFrame, InstanceRecord
 │   └── lib/                         # api client, session guards, formatters
 ├── shared/                          # imported by server, sitesvc and admin
+│   ├── mail/                        # the one email system: transport + tmpl templates
 │   ├── license/                     # payload, sign, verify, trusted keys, plans
 │   ├── models/                      # Instance, User, Settings
 │   └── cmd/lkctl/                   # issue and inspect licences by hand
@@ -191,6 +191,37 @@ person is later granted. `GET /auth/verify` therefore peeks before it consumes:
 a token belonging to a passwordless row answers `{"needs_password":true}` and is
 left unspent.
 
+### Email
+
+`shared/mail` is the only email system. It owns the SMTP conversation, the RFC
+5322 envelope and the look of every message; `server`, `admin` and `sitesvc`
+each import it and none of them builds a subject line, a MIME part or a colour.
+Before this existed the transport was copied three times, and the copies had
+already diverged once — the 465-implicit-TLS fix landed in one of them while
+the others silently delivered nothing.
+
+`Sender` is a value, not a singleton: `server/internal/notify` builds one per
+notification channel from the channel document in Mongo, while `sitesvc` builds
+one at boot and `admin` holds one in `admin/internal/mail.Default`, alongside
+its other boot-time singletons. Callers only ever see typed methods —
+`SendVerification`, `SendExpiring`, `SendMonitorAlert`, `SendEnquiry` and the
+rest, grouped by owner into `account.go`, `licence.go`, `billing.go`,
+`monitor.go` and `contact.go`.
+
+Every message is `multipart/alternative`, so each one is two templates:
+`templates/<name>.html.tmpl` and `.txt.tmpl`, embedded with `go:embed`. They
+define `subject`, `title`, `pill` and `body`; `layout.html.tmpl` and
+`layout.txt.tmpl` provide the chrome and the helper templates (`p`, `lead`,
+`button`, `well`, `note`, `rows`, `chip`) that the bodies compose. One template
+set is parsed per message rather than one big set, because every message
+defines those same four names. **`subject` is defined in the txt file only** —
+`html/template` would escape an ampersand in an instance name and mail clients
+show subjects verbatim.
+
+`shared/mail/render_test.go` renders all of them and fails if a template exists
+that no case covers, which is the only thing standing between a mistyped field
+and a boot-time panic — the templates are parsed in `init()`.
+
 ### Shared provisioning
 
 `shared/provision` (`instance.go`, `slug.go`, `user.go`) holds the slug rules, reserved names and instance/user creation logic that both `server` and `admin/internal/cloudprov` need, so there is no longer a second copy to drift: `cloudprov.CreateInstance` calls straight into it to create a control-plane instance and its owner from a customer request.
@@ -526,6 +557,8 @@ All three apps are **one visual system**, anchored on the logo navy. What differ
 
 `adminsite/app/globals.css` holds `site/app/globals.css`'s token blocks **copied verbatim** — same names, same values. `web/app/globals.css` holds the same tokens too, but only the **dark** values, since it does not switch. **Change a token in all three files in the same commit; nothing enforces the match automatically**, the same shape of hazard as sitesvc's mirrored slug rules.
 
+There is a **fourth** copy, and it is the one people forget: `shared/mail/templates/layout.html.tmpl` carries web/'s dark values as literal hex. Email clients support neither `var()` nor a reliable `prefers-color-scheme`, so the token indirection is simply not available there — an email is read before the recipient clicks through to the control plane, and the two should not look like different products. Every colour in the email system is in that one file, in the same way no component in the three web apps carries a hex.
+
 Tailwind in all three maps `var(--…)` references only, so **no component in any of them may carry a hex value**. The names differ per app on purpose, because each app has its own subject: `site/` calls the semantic three `--up`/`--pend`/`--down` for monitor state, `adminsite/` aliases them to `valid`/`warn`/`expired` for licence state, and `web/` to `success`/`warning`/`danger`. Same colours, honest names on each side.
 
 `web/` stores its tokens as **RGB channel triplets** with the hex in a trailing comment, and derives `--token: rgb(var(--token-rgb))` from them. That is not a style preference: the console leans on Tailwind's opacity modifiers (`bg-danger/10`, `border-accent/50`, `ring-accent/30`) in a way the other two do not, and `<alpha-value>` only compiles against channels. Keep the hex comments — they are what lets the three token blocks still be diffed by eye. `web/` also adds three tokens site/ has no use for: `--accent-hover` and `--down-hover` (site/ brightens with a CSS `filter`, which a Tailwind colour token cannot do) and `--well`, the floor beneath the ground for install one-liners, key blobs and run logs — surfaces showing machine output rather than interface.