Add an additive Railway integration layer - #2011

Deploy the self-host image as a **single Railway service** instead of
needing separate proxy and cron services beside it, and remove the
upstream publishing workflows that a fork should not run.

## Why

The self-host image serves the backend on `BACKEND_PORT` and the dashboard
on `DASHBOARD_PORT`. Railway routes a domain to exactly one target port, so
deploying it previously took two extra services:

- a Caddy service path-routing `/api/*` to the backend and the rest to the dashboard
- a cron service curling a hand-maintained list of internal endpoints

Both now run inside the container.

## Design

The layer is **additive**. Everything new lives in `railway/`,
`docker/railway/`, and one new workflow; the only edit to an existing file
is a single line registering the tests in the vitest workspace. Merging
upstream stays conflict-free.

### `railway/proxy.mjs`

Binds Railway's `PORT` and routes `/api/*` to the backend, everything else
to the dashboard — the same split the Caddy config used, so an existing
bare-origin API URL stays valid. Two improvements over what it replaces:

- **The health endpoint is real.** It reports healthy only when both
  upstreams answer, and probes the backend with `?db=1` so database
  connectivity is verified rather than just that a process is listening.
  The path it replaces returned a static `ok`, which let Railway mark a
  deployment healthy while the app behind it was still migrating or had
  crashed.
- **Forwarded headers are preserved and appended to**, not overwritten, so
  the backend still resolves the real client IP, scheme, and host.

No npm dependencies, since this layers onto a prebuilt image whose
`node_modules` belongs to the application.

### `railway/cron.mjs`

Drives the scheduled endpoints from `apps/backend/vercel.json` — the same
file the backend imports in `src/server/cron-monitor.ts`, so the schedule
cannot drift. A hand-maintained list goes stale whenever upstream changes
it, which had already happened: only three of the five configured jobs
were being fired, leaving `workflow-engine-step` and
`growth-watchdog-step` never running.

Firings carry the `vercel-cron` user agent that `cron-monitor.ts` requires
before opening a Sentry check-in, so self-hosted crons stay observable, and
a job still in flight is skipped rather than started again.

### `railway/entrypoint.sh`

Wraps the image's own entrypoint unmodified and derives what Railway
already provides: `DATABASE_URL`, the public domain, and the trusted-proxy
setting. Derivation never overrides an explicit value in either the
`HEXCLAVE_` or the legacy `STACK_` spelling, since the application refuses
to start when the two disagree.

### `docker/railway/Dockerfile`

Layers the above onto an already-built server image rather than adding a
second way to build the monorepo, so iterating on the proxy or cron runner
takes seconds instead of a full Next.js build. The new workflow builds it
against the base image from the same commit.

## Fork hygiene

Enabling Actions on a fork activates every inherited upstream workflow.
These are removed because they publish to shared external registries or
tag upstream maintainers:

- `npm-publish.yaml`
- `swift-sdk-publish.yaml`
- `dashboard-release.yaml`
- `table-of-contents.yaml`
- `auto-assign.yaml`
- `reviewers-assignees.yml`

CI and the Docker image builds are kept.

## Tests

Cover the crontab parser and matching rules, the proxy's routing, health
aggregation and header forwarding against real sockets, and the
entrypoint's environment derivation.

    pnpm test run --project railway

Notes from validating the layer on a real Railway project, all of which
cost time to work out from logs:

- A second service against an already-seeded database needs
  `HEXCLAVE_SKIP_SEED_SCRIPT=true`. The seed script tries to rewrite the
  internal project's environment config overrides, aborts, and takes the
  container down with it.
- Exactly one service per project should run cron. Two schedulers on one
  database produce `poller-stale-outgoing-requests` recovery errors as
  each cleans up rows the other is mid-way through.
- The backend's per-request logging exceeds Railway's 500 logs/sec
  per-replica cap under load, and Railway drops the excess rather than
  buffering it — which can swallow the errors you are reading logs to find.

Email sending was SMTP-or-nothing. The config schema already had a
`provider` field accepting `'resend'`, but nothing read it anywhere in the
codebase — selecting it fell through to the SMTP branch and threw
`Email config is not complete despite not being shared`. This makes the
field real and adds an HTTP transport beside the existing SMTP one.

## Why one transport covers both providers

useSend is Resend-compatible for the fields we send. The request bodies are
identical (`from`, `to`, `subject`, `html`, `text`), both authenticate with
`Authorization: Bearer`, and both honour `Idempotency-Key`. They differ only
in the send path (`/emails` vs `/api/v1/emails`) and in that useSend is
self-hosted, so it has no default origin. Their success responses name the
id differently, which does not matter because it is discarded.

## Changes

**`LowLevelEmailConfig` is now a union over `transport`.** `'smtp'` keeps
the existing nodemailer path unchanged; `'http'` carries a provider, API
key, and base URL. Making it a discriminated union rather than a bag of
optional fields means the compiler locates every construction site.

**Retries can no longer duplicate a delivery.** A 5xx from an HTTP provider
is ambiguous — the message may already be queued — so `Idempotency-Key` is
sent, and the outbox passes its row id, which is stable across every retry
of the same email.

**Failures are classified like the SMTP path**, since the caller retries on
`canRetry`: a rejected API key and a rejected payload are permanent, while
rate limits, server errors, and an unreachable provider are retryable.

**A tenant-supplied base URL is an SSRF vector**, so
`ssrf-protection/email-http.ts` mirrors the existing SMTP egress policy:
HTTPS only, and no hosts resolving to private or reserved addresses. It is
inert in development and test. Note that a useSend instance reached over a
provider's internal network is rejected by default and needs
`HEXCLAVE_ALLOW_STANDARD_EMAIL_PRIVATE_HOSTS=true`, or its public domain.

Provider credentials are kept out of error reports the same way the SMTP
password already is.

## Compatibility

Adding optional fields and one enum value is backwards-compatible, so no
config migration is required. The legacy admin `email_config` shape models
only SMTP, so a project on an HTTP provider reports `type: 'standard'` with
empty SMTP fields there; its real settings live under `emails.server` in the
config API, which is what the dashboard reads and writes.

JavaScript execution through Freestyle was failing in production with
`js-execution-freestyle-failed` on every email render, and the Vercel
Sandbox fallback then threw before making a request, turning it into a
hard 500 on `/api/latest/emails/render-email`.

## What was actually wrong

The pinned `freestyle@0.1.63` calls `serverless.runs.create()`, which
posts to `POST /execute/v3/script` on `https://api.freestyle.sh`.

Freestyle has since retired serverless code execution and moved to a VM
API on a different host. Diffing the SDKs: `0.1.63` declares
`readonly serverless: ServerlessNamespace`, and `0.2.2` has no such
namespace at all — its `DEFAULT_BASE_URL` is `https://beta-api.freestyle.sh`
and it exposes `/v5/vms`. Current API keys are unknown to the old host, so
it answers `Invalid API key` no matter how valid the key is; the old
endpoint is simply gone (`404 ROUTE_NOT_FOUND`) on the new one.

No environment variable could fix this — the endpoint no longer exists.

## The new engine

Execution now runs on a long-lived VM addressed by slug, created from
`freestyle/ubuntu` (whose image already has Node.js on PATH, so nothing
is installed before the first run). Measured against the live API:

- create: ~0.8s, and only on the very first run
- resume from paused: ~0.1s, because Freestyle keeps the VM's memory
- warm render: ~1s

Runs share the VM, so isolation between them is explicit:

- **`node_modules` is keyed by a hash of the module set.** Runs needing the
  same packages share a directory and therefore one `npm install`; runs
  needing different versions can never resolve each other's modules.
- **Every run writes uniquely named files** in that directory. Four
  concurrent renders were verified to return four distinct results with no
  cross-talk.
- **Per-run files are removed afterwards**, since the VM outlives them and
  the disk would otherwise grow without bound. Cleanup failure is reported
  but never replaces the execution result.
- **A lost create race is recovered**, not failed: two cold invocations can
  both miss the slug lookup, and the loser re-reads the winner's VM.

## Local development

`docker/dependencies/freestyle-mock` still speaks the retired serverless
contract, and local development and E2E depend on it. The mock key path
therefore talks to it with a direct request rather than through the SDK,
which no longer has a namespace for that shape. Using the mock key outside
development or test remains refused — it executes code with no isolation.

## Dependency

`freestyle` moves to `^0.2.2`. The whole 0.2 line is newer than
`minimumReleaseAge` allows, so it is listed in `minimumReleaseAgeExclude`
with a note to remove the entry once it has aged past the threshold. This
is a deliberate exception: 0.1.x cannot authenticate at all, so there is no
older version that works.

`vi.fn(async () => ...)` records calls as an empty tuple, so reading a
call's arguments failed to typecheck:

    TS2493: Tuple type '[]' of length '0' has no element at index '0'

Declaring the mock's parameters gives the recorded calls their real
`[string, RequestInit]` shape, which also removes the two casts that were
papering over the same gap.

## Why

`emails.server.provider` already had a `resend` value, but it means **Resend
over SMTP** (`smtp.resend.com:465`, username `resend`, API key as the SMTP
password). The earlier commit on this branch redefined `resend` to mean the
HTTP API and required an `apiKey` alongside it, which would have failed config
validation for every project already saved with the SMTP-shaped Resend config.

## What changed

**New provider values, no migration needed.** The HTTP transports are
`resend-api` and `usesend-api`; `resend` keeps its existing SMTP meaning, so
the change is purely additive and existing configs render unchanged.

**Legacy `email_config` gains `type: "http"`.** `emailConfigSchema` requires
every SMTP field when `type` is `standard`, so reporting an HTTP-provider
project as `standard` with empty host/port/username would have failed
validation on read and taken down the whole admin project endpoint. The new
type carries `email_provider`, `api_key` and `base_url` instead, and
`sender_name`/`sender_email` are now required for both transports.

**`/internal/send-test-email` accepts either transport.** `type` defaults to
`standard` so existing SDK callers keep working. HTTP test sends go through the
same egress policy as saved configs, since the base URL is admin-supplied. The
error reporter no longer receives the SMTP password or the provider API key.

**Dashboard.** Both email settings surfaces offer *Resend API*, *useSend API*,
*Resend (SMTP)* and *Custom SMTP*, with an API key field and -- for useSend,
which is self-hosted and has no default origin -- a required `https://` base
URL. Saving replaces `emails.server` wholesale, so switching transports clears
the previous one's credentials.

**SDK.** `AdminEmailConfig` gains an `http` variant and `sendTestEmail` accepts
either shape.

**`newly-created-projects`.** Its `email_setup.provider` union is now derived
from a single exported `EMAIL_SETUP_PROVIDERS` const, so the two yup schemas
and the row type can no longer drift when a provider is added.

## Verification

Run after `pnpm build:packages` and the backend codegen:

- `turbo typecheck`: `@hexclave/backend`, `@hexclave/shared` and
  `@hexclave/template` clean. Remaining repo failures are pre-existing and
  untouched here -- `@hexclave/dashboard` cannot resolve `next-env.d.ts` asset
  module declarations or `@/generated/bundled-type-definitions` without a Next
  build, `@hexclave/internal-tool` is missing `@types/node`, and
  `@hexclave/example-demo-app` cannot find `LayoutProps`.
- `turbo lint --max-warnings=0`: 31/31 packages clean.
- `pnpm test run apps/backend/src/lib/emails.tsx
  apps/backend/src/lib/emails-low-level.tsx apps/backend/src/lib/ssrf-protection`:
  47/47 pass, covering the 16 email-transport tests added on this branch.
- `packages/shared` suite: 439 pass, 5 skipped. The one failure is a stale
  inline snapshot for `productLineId` whose message comes from
  `schema-fields.ts:614`; no line of this diff touches it.

Not run here: the Prisma-backed tests in `apps/backend/src/lib/config`, which
need a Postgres instance this environment has no Docker daemon to start. They
fail with `P1001 Can't reach database server`, not on any code in this diff.