LP を signalarm.app (Cloudflare Pages) で配信し、API を api.signalarm.app に揃える

## 背景

製品名が Signalarm に決まり、TestFlight 配布と実機での E2E (外部 API → push → AlarmKit 発火) が通った (2026-09-12)。公開に向けて、LP を GitHub Pages (`bannzai.github.io/Alarmify/`) から独自ドメインの Cloudflare Pages へ移し、API の公開 URL も同じドメインに揃える。

ドメインは **signalarm.app** に決定 (2026-09-12。年 約 $14、空き確認済み)。購入は Cloudflare のダッシュボードでしかできないため bannzai が行う (#25 に記載)。購入までは zone が無いので、本 issue の agent 作業は「Pages プロジェクトの作成と `*.pages.dev` での配信 → LP の刷新」まで先に進め、カスタムドメインの接続と API の URL 差し替えは購入後に行う。

## 構成

| 用途 | URL | 実体 |
| --- | --- | --- |
| LP・法務ドキュメント・API リファレンス・連携レシピ | `https://signalarm.app/` | Cloudflare Pages (静的サイト。既存の `docs/` を移す) |
| 外部サービス向け API | `https://api.signalarm.app/v1/alarms` | Cloud Functions `alarmsApi` へのカスタムドメイン (Cloud Run のドメインマッピング、または Firebase Hosting の rewrite。選定は ADR に記録する) |

Cloudflare のアカウントは既存 (Pages プロジェクト `kotobacho` 等と同じアカウント。`CLOUDFLARE_API_TOKEN` は `.envrc`、アカウント ID は `wrangler whoami` で確認できる)。既存の配信例: bannzai/dashboard の `.github/workflows/collect-and-deploy.yml` (wrangler で Pages へ配信)。

## やること

### LP を Cloudflare Pages で配信する (ドメイン購入前に着手できる)

- `docs/` 配下 (LP `index.html`・法務ドキュメント・`api.md`・`recipes/`) を Cloudflare Pages で配信する。Jekyll (`docs/_config.yml`) 前提の markdown はそのままでは配信できないため、静的 HTML への変換手段 (ビルドスクリプト) を用意するか、markdown を HTML に置き換える
- GitHub Actions で main へのマージ時に Pages へ配信する workflow を追加する (bannzai/dashboard の deploy を参考にする)。Secrets は environment に置き、正準キー名は env-secret-registry skill に従う。登録が必要な Secret は #25 に追記して依頼する
- LP の内容を `/landing-page-builder` skill で刷新する。訴求は `documents/PROJECT.md` のコンセプト (「Webhook を iPhone の本物のアラームにする」) とターゲット (オンコールのエンジニア・Home Assistant 利用者・サーバー側の予定で起こされたい人)。実機 E2E で通った導線 (API トークン発行 → curl 1 行 → 本物のアラーム) を主役にする。`bash ~/.agents/skills/landing-page-builder/scripts/verify-lp.sh --app-store-support --has-account ` が pass すること
- GitHub Pages 側は、カスタムドメインへの切り替え後にリダイレクトを置くか停止する (App Store の Support URL・アプリ内のリンク・`fastlane/metadata` の URL を新ドメインへ差し替える)

### ドメイン購入後 (bannzai の購入を待つ)

- Cloudflare Pages のカスタムドメインに `signalarm.app` を接続する (API で行う。DNS も同じ zone なので自動)
- `api.signalarm.app` を Functions の `alarmsApi` に向ける。方式を決めて ADR を書く (`documents/adr/`)。決めたら `docs/api.md`・`docs/recipes/*`・アプリ内の連携レシピ (`Alarmify/Recipes/`) の `api.alarmify.app` プレースホルダーと Functions の URL 直書きを `api.signalarm.app` に置き換える
- `documents/PROJECT.md` の名称の節に、ドメインの決定を追記する

## 完了条件

- [ ] `https://signalarm.app/` で LP が配信され、`verify-lp.sh --app-store-support --has-account` が pass している
- [ ] `https://signalarm.app/api` (または相当のパス) で API リファレンスと連携レシピが読める
- [ ] `curl -X POST https://api.signalarm.app/v1/alarms` が Functions の `alarmsApi` に到達する (未認証で 401 が返る)
- [ ] main へのマージで Pages が自動配信される workflow があり、1 回成功している
- [ ] `api.alarmify.app` の記述がリポジトリに残っていない

## 依存

- signalarm.app の購入 (bannzai。#25)。購入前は `*.pages.dev` の URL で LP を配信し、購入を待つ間は本 issue にその旨をコメントして止める (ポーリングしない)
- API の公開 URL の決定は #25 の「API の公開 URL をどうするか決める」を本 issue で引き取る (signalarm.app に決定)

## セッション再開

```sh
cd /Users/bannzai/ghq/github.com/bannzai/Alarmify
claude --resume 808e78eb-6c3d-42cf-b4d3-84aeb6456842
```

Start with docs/index.html, docs/_config.yml, the docs/ tree, and the existing bannzai/dashboard .github/workflows/collect-and-deploy.yml; inspect documents/PROJECT.md and the app links in Alarmify/Recipes/. Run verify-lp.sh against the landing page and test the Pages deployment workflow. Done means the static docs deploy automatically, the LP check passes, and the documented API and domain endpoints meet the listed checks once the domain is purchased.

Written by the indexing model from the issue text.