gdo in the vel's own stack, and portal v0.5.2

The mailer moves in. Portal decides what to send and publishes it on
this NATS; gdo is what hands it to a mail server, and it belongs here
rather than shared, so the vel's mail leaves on the vel's own terms. It
has no mail server of its own and relays through the host's - on kasse,
Klingenberg Bygg's postfix - which is the one thing this stack borrows
and the one line that changes if the vel ever gets a host of its own.

Also:

- portal v0.5.2, four releases on from the v0.3.36 this pinned.
- The Kanidm setup makes the onboarding service account and its token.
  The vel's desks invite neighbours, and portal needs a token to do it;
  without one every invite fails closed. It goes in
  idm_people_on_boarding, which may create a person and issue a first
  credential reset and nothing else, plus idm_people_pii_read so an
  invite finds someone who already has an account instead of making
  them a second one.
- The deploy workflow runs. It was pointed at a `tomtervel` runner
  label that has never existed, so every push queued and did nothing.
  It now runs on kasse's host runner, which is not root and may run one
  argumentless script that pulls this repo and brings the stack up.
- The hosts default to vel.klingenbergbygg.no and
  id.vel.klingenbergbygg.no, which is where this actually runs. Both
  already resolve to kasse.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -111,3 +111,23 @@ content repo's workflow matched to it.
 Mail (a person's reset link is a token you hand them), monitoring, and
 the vel's current website at tomtervel.no, which stays where it is
 until the vel points the apex at PORTAL_HOST.
+
+## Mail
+
+Portal decides what to send - a `mail:` on a state in the content, or an
+invite - and publishes it on this stack's NATS. `gdo` is what hands it to
+a mail server, and it runs here, in the vel's own stack, so the vel's mail
+leaves on the vel's own terms.
+
+It has no mail server of its own. It relays through the host's, which on
+kasse is Klingenberg Bygg's postfix on port 25, reached from the container
+as `host.containers.internal`. That is the one thing in this stack the vel
+borrows, and the one thing that changes if the vel ever moves to a host of
+its own: point `SMTP_HOST` at whatever that host runs.
+
+`site.yaml` in the content repo needs a `mail.from`, or portal has nothing
+to send from and says so in its log.
+
+Replies are not read yet: `JMAP_URL`, `JMAP_TOKEN` and `MAIL_REPLY_DOMAIN`
+turn a reply into a note on the record it answers, and none of them are set
+here.