No way to reply to a calendar invitation

# No way to reply to a calendar invitation

## What's missing

`hey` can read an attendance status but never write one. `hey event list --json` returns
`attendances[].status` (`needs_action`, `accepted`, `tentative`, `declined`) and
`manage_attendance`, yet there is no command to answer an invitation.

Checked against `main`:

- `.surface` has no `rsvp`, `attend`, `accept`, `decline`, `tentative` or `going` entry.
`hey event` is `add`, `day`, `delete`, `edit`, `list`, `week`, and none of their flags
touches attendance status.
- `outbound_replies` and `ical_event` appear nowhere in the repository.
- The same two strings are absent from `hey-sdk`'s `openapi.json`, whose `Attendance`
schema is read-only (`id`, `email_address`, `name`, `status`).
- The calendar TUI reads `Attendances` only to render the guest list; it offers no reply
action either.

To avoid a likely misreading: `hey event add --invite` / `hey event edit --invite` do write
attendance, through `calendar_event[attendance_email_addresses][]`, but that is *inviting
other people to your own event*. It is not answering an invitation addressed to you. The
two are unrelated, and only the first is covered today.

## Why a command on the event will not work

An invitation you have not answered has no calendar event at all. I checked this on a real
account: invitations sitting in the Imbox unanswered (including recurring ones) appear in
no calendar, on no date, while every answered one is present with
`attendances[].status = accepted`. HEY creates the event *as part of* replying.

So there is no event id to address, and `hey event rsvp ` cannot be the shape.
The invitation exists only as an email entry, so the command has to be addressed to the
thread.

## What the web app does

Clicking Yes on an invitation submits this form:

```http
POST /entries/{entry_id}/ical_events/{ical_event_id}/outbound_replies
Content-Type: application/x-www-form-urlencoded

calendar_event_outbound_reply[sender_email_address]=you@hey.com
calendar_event_outbound_reply[status]=accepted # or tentative, or declined
calendar_event_outbound_reply[calendar_id]=3357
```

It answers with a 302. The name is apt: one request does two things, filing the event on
the chosen calendar and sending the iCalendar REPLY to the organizer. The form's own label
says "Add to calendar and reply…", and it becomes "Change your reply…" once an event
exists — though that wording is not a reliable indicator of whether you have answered, so
a command should not key on it.

`entry_id` is already reachable: it is the entry id from `hey thread read --json`.

## The one wrinkle

`ical_event_id` is only available from the HTML turbo-frame:

```
GET /entries/{entry_id}/ical_events
```

`GET /entries/{entry_id}/ical_events.json` returns 406, and so does the same path with
`Accept: application/json`. The id has to be parsed out of the markup, next to the
`outbound_replies` form action. `internal/htmlutil` looks like the precedent for that, but
I would rather ask than guess: is there a JSON route I have not found, or would parsing the
frame be acceptable here?

## Proposed shape

```
hey thread rsvp --yes | --no | --maybe [--calendar ]
```

Addressed to the thread, since no event exists yet. `--calendar` defaults to the option the
frame marks `selected`. Changing an existing reply could later take an event id, but that
seems worth keeping out of a first change.

Happy to send a PR along these lines if the approach and the command name suit you.

Start with the thread JSON entry id from `hey thread read --json`, then inspect `internal/htmlutil` and the `hey-sdk` `openapi.json` findings. Determine how to obtain `ical_event_id` from the HTML frame and whether that approach is acceptable. Done means a thread-level RSVP command can select a calendar and submit accepted, tentative, or declined replies.

Written by the indexing model from the issue text.