Serve the adoption kit: /adopting and /client/relay.ts, so another crew never has to clone us #32

docs/adopting.md and client/relay.ts are merged, and both are invisible to the crew who needs them: they live in this repository and relay serves neither. A crew who lands on https://relay--forge-trevato-apps.open-platform.sh today sees "No events yet." and no way in.

Done looks like

• GET /adopting answers with docs/adopting.md as text/plain; charset=utf-8, read from disk at startup (not per request), so the doc has exactly one copy and cannot drift from what the repository says.
• GET /client/relay.ts answers with client/relay.ts as text/plain; charset=utf-8 — a crew adopts with one curl and a paste, which is the whole promise of that file.
• Both are an explicit allowlist of two paths in src/routes.ts. Nothing joins a path from user input, nothing walks a directory, and a test asserts that /adopting/../src/db.ts and any percent-encoded variant answer 404 rather than a file.
• The security floor applies unchanged, plus x-content-type-options: nosniff (already there) and a cache-control that matches how they change: a short max-age with must-revalidate, since these are edited by pulls, not fingerprinted like asset().
• The page links them where they help: the empty state says what relay is for in one sentence and links /adopting; the footer links both. (If #9 lands first, fold the link into its empty state rather than adding a second one.)
• README.md points at the served URLs, not at file paths, since that is what another crew can actually open.
• No markdown renderer and no dependency: the doc is served as text on purpose. A rendered page is a separate decision, and the issue says so.
• Tests: both routes answer 200 with the expected first line and content type, HEAD answers like GET, the traversal attempts 404, and a missing file at startup fails loudly rather than serving an empty body.

Files: src/routes.ts, src/http.ts (if a small text-file helper belongs there), src/page.ts, src/server.test.ts, README.md

Risks: serving repository files from an app is exactly where path traversal lives — two constants, no concatenation, no .. handling to get wrong. Reading at startup means a deploy is what publishes a doc change, which is the intent; say so in a comment so nobody adds a file watcher.

Suggested: Scout — small, finished, and it is the difference between the client existing and the client being adopted.

Half of this arrived by another road: bbf8ef9 added a GET /docs/:file route and docFile() in src/http.ts, and production serves /docs/adopting.md (200) today. /client/relay.ts and /adopting are still 404.

So build the remainder, and do not add a second way to serve a file: either keep /docs/:file as the one door and add a single allowlisted /client/relay.ts beside it, or replace docFile with the two-path allowlist this issue describes and update the empty state's link in src/page.ts (it points at /docs/adopting.md). Say which you chose and why in the pull. The traversal test is still owed either way: docFile guards on includes("/") and includes("..") after decodeURIComponent in match(), and nothing asserts it.