## Why

A guest who opens their invitation cannot see who is inviting them. The page carries the
couple's names and the ceremony, but the *host* — the parent or parents actually holding the
event, never the bride and groom — appears nowhere. The
only trace is a bare phone number at the very bottom of the page with no name attached to it,
inherited from a wedding-wide setting that every event shares.

That is wrong on two counts. A printed Bangladeshi wedding invitation names its host at the
foot of the card, and it is the host a guest phones with a question. And a wedding-wide
number cannot be right when one family hosts the Mehedi and another hosts the Walima —
which is exactly the arrangement the per-event model (design D11/D12) was built to support.

## What Changes

- Events gain three fields: **host name 1** (required), **host name 2** (optional) and a
  **host phone** (required). They are filled in on the Create event modal and editable on the
  Edit event modal, where they sit in their own section immediately **before** Card design.
- The guest invitation page (`/i/{token}` and `/e/{slug}`) renders a **host block** centred
  at the foot of the page, headed **"Invited By"**: the host name(s) on one line, the phone
  beneath it. One name renders alone; two render joined by the word **"And"**.
- **BREAKING (guest-visible):** the wedding-wide `host_contact_phone` **stops rendering** on
  the invitation page — the per-event host block replaces it there. The wedding-wide value
  stays in the database and keeps rendering on the cancellation and open-RSVP surfaces, which
  this change does not touch.
- **BREAKING (API):** `POST /admin/events` gains two required fields. Any caller creating an
  event without a host name and phone is rejected with a 422.
- A migration adds the columns and **backfills every existing event**: the phone from the
  wedding's `host_contact_phone`, which is already a family contact number, and the host name
  from a visible placeholder — because the host is a parent and no parent name exists anywhere
  in the database to derive one from.

## Capabilities

### New Capabilities

None. This extends two existing capabilities rather than introducing a new one — the host is
an attribute of an event, and where it renders is part of how the invitation is composed.

### Modified Capabilities

- `event-management`: events gain required host name and host phone, plus an optional second
  host name; both the create form and the event editor modal must collect them, and the
  editor must place them in a dedicated section ahead of Card design.
- `invitation-presentation`: the invitation's below-the-fold region gains a host block naming
  who is inviting the guest, and the wedding-wide host phone is removed from that surface.

## Impact

**Database** — `event` gains `host_name_1` (NOT NULL), `host_name_2` (nullable), `host_phone`
(NOT NULL). One Alembic migration, with a data backfill that must run before the NOT NULL
constraints are applied. `wedding.host_contact_phone` is unchanged.

**API** — `api/app/models/wedding.py` (`Event`), `api/app/routers/admin_events.py`
(`AdminEventRead`, `EventCreate`, `EventUpdate`), `api/app/schemas/invitation.py` (the event
payload the invitation page reads). Phone normalisation reuses the existing E.164 helper the
guest importer already uses, so a host number is stored the same way a guest's is.

**Web** — `web/components/admin/EventEditorModal.tsx` and the create-event form in
`web/components/admin/EventsView.tsx` gain the fields; `web/components/InvitationShell.tsx`
gains the host block and loses the wedding-wide phone; `web/lib/view-models.ts` gains the
host fields on `EventView`. `web/lib/api/schema.d.ts` must be regenerated (`make client`) or
CI's client-freshness check fails.

**Not affected** — the invitation card design itself carries no guest or host data and is not
touched; reminders, messaging, headcounts and the guest model are all unchanged.

**Risk** — the backfill cannot produce a true host name for any existing event, so every one
of them carries a placeholder until an operator edits it. Where `host_contact_phone` is also
NULL the phone is a placeholder too. Both must be visibly wrong rather than plausible, and
operators must be told to go and correct them.