Rename "channels" to "conversations."

The term "channel" for a conversational container has a long and storied history, but is mostly evocative of IRC and of other, ah, "nerd-centric" services. It does show up in more widespread contexts: Discord and Slack both refer to their primary conversational containers as "channels," for example. However, I think it's unnecessary jargon, and I'd like to do away with it.

To that end, this change pervasively changes one term to the other wherever it appears, with the following exceptions:

* A `channel` concept (unrelated to conversations) is also provided by an external library; we can't and shouldn't try to rename that.
* The code to deal with the `pilcrow:channelData` and `pilcrow:lastActiveChannel` local storage properties is still present, to migrate existing data to new keys. It will be removed in a later change.

This is a **breaking API change**. As we are not yet managing any API compatibility promises, this is formally not an issue, but it is something to be aware of practically. The major API changes are:

* Paths beginning with `/api/channels` are now under `/api/conversations`, without other modifications.
* Fields labelled with `channel…` terms are now labelled with `conversation…` terms. For example, a `message` `sent` event is now sent to a `conversation`, not a `channel`.

This is also a **breaking UI change**. Specifically, any saved paths for `/ch/CHANNELID` will now lead to a 404. The corresponding paths are `/c/CONVERSATIONID`. While I've made an effort to migrate the location of stored data, I have not tried to provide adapters to fix this specific issue, because the disruption is short-lived and very easily addressed by opening a channel in the client UI.

This change is obnoxiously large and difficult to review, for which I apologize. If this shows up in `git annotate`, please forgive me. These kinds of renamings are hard to carry out without a major disruption, especially when the concept ("channel" in this case) is used so pervasively throughout the system.

I think it's worth making this change that pervasively so that we don't have an indefinitely-long tail of "well, it's a conversation in the docs, but the table is called `channel` for historical reasons" type issues.

Merges conversations-not-channels into main.

1 files changed, 42 insertions, 55 deletions

diff --git a/docs/api/events.md b/docs/api/events.md
index 570dffa..e692f82 100644
--- a/docs/api/events.md
+++ b/docs/api/events.md
@@ -28,13 +28,11 @@ sequenceDiagram
 	end
 ```
 
-The core of the service is to facilitate conversations between users. Conversational activity is delivered to clients using
-_events_. Each event notifies interested clients of activity sent to the service through its API.
+The core of the service is to facilitate conversations between users. Conversational activity is delivered to clients using _events_. Each event notifies interested clients of activity sent to the service through its API.
 
 ## Asynchronous completion
 
-A number of endpoints return
-`202 Accepted` responses. The actions performed by those endpoints will be completed before events are delivered. To await the completion of an operation which returns this response, clients must monitor the event stream for the corresponding event.
+A number of endpoints return `202 Accepted` responses. The actions performed by those endpoints will be completed before events are delivered. To await the completion of an operation which returns this response, clients must monitor the event stream for the corresponding event.
 
 ## `GET /api/events`
 
@@ -46,14 +44,11 @@ This endpoint is designed for use with the [EventSource] DOM API, and supports s
 
 ### Query parameters
 
-This endpoint requires a
-`resume_point` (integer) query parameter. The event stream will collect events published after that point in time. The value must be obtained by calling the [
-`GET /api/boot`](./boot.md) method.
+This endpoint requires a `resume_point` (integer) query parameter. The event stream will collect events published after that point in time. The value must be obtained by calling the [`GET /api/boot`](./boot.md) method.
 
 ### Request headers
 
-This endpoint accepts an optional `last-event-id` (string) header. If present, the value must be the value of the
-`id` field of the last message processed by the client. The returned event stream will begin with the following message. If absent, the returned event stream will begin from the start of the event collection.
+This endpoint accepts an optional `last-event-id` (string) header. If present, the value must be the value of the `id` field of the last message processed by the client. The returned event stream will begin with the following message. If absent, the returned event stream will begin from the start of the event collection.
 
 This header is set automatically by `EventSource` when reconnecting to an event stream.
 
@@ -69,7 +64,7 @@ data: {
 data:   "type": "message",
 data:   "event": "sent",
 data:   "at": "2024-09-27T23:19:10.208147Z",
-data:   "channel": "C9876cyyz",
+data:   "conversation": "C9876cyyz",
 data:   "sender": "U1234abcd",
 data:   "id": "M1312acab",
 data:   "body": "beep"
@@ -78,9 +73,7 @@ data: }
 
 The service will keep the connection open, and will deliver events as they occur.
 
-The service may terminate the connection at any time. Clients should reconnect and resume the stream, using the
-`last-event-id` header to resume from the last message received. The
-`id` of each event is an ephemeral ID, useful only for this purpose.
+The service may terminate the connection at any time. Clients should reconnect and resume the stream, using the `last-event-id` header to resume from the last message received. The `id` of each event is an ephemeral ID, useful only for this purpose.
 
 Each event's `data` consists of a JSON object describing one event. Every event includes the following fields:
 
@@ -133,66 +126,63 @@ These events have the `event` field set to `"created"`. They include the followi
 | `id`   | string    | A unique identifier for the newly-created user. This can be used to associate the user with other events, or to make API calls targeting the user. |
 | `name` | string    | The user's name.                                                                                                                                   |
 
-## Channel events
+## Conversation events
 
-The following events describe changes to [channels](./channels-messages.md).
+The following events describe changes to [conversations](conversations-messages.md).
 
-These events have the `type` field set to `"channel"`.
+These events have the `type` field set to `"conversation"`.
 
-### Channel created
+### Conversation created
 
 ```json
 {
-  "type": "channel",
+  "type": "conversation",
   "event": "created",
   "at": "2024-09-27T23:18:10.208147Z",
   "id": "C9876cyyz",
-  "name": "example channel 2"
+  "name": "example conversation 2"
 }
 ```
 
-Sent whenever a new channel is created.
+Sent whenever a new conversation is created.
 
 These events have the `event` field set to `"created"`. They include the following additional fields:
 
-| Field        | Type                | Description                                                                                                                                                 |
-| :----------- | :------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `at`         | timestamp           | The moment the channel was created.                                                                                                                         |
-| `id`         | string              | A unique identifier for the newly-created channel. This can be used to associate the channel with other events, or to make API calls targeting the channel. |
-| `name`       | string              | The channel's name.                                                                                                                                         |
-| `deleted_at` | timestamp, optional | If set, the moment the channel was deleted.                                                                                                                 |
+| Field        | Type                | Description                                                                                                                                                                |
+| :----------- | :------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `at`         | timestamp           | The moment the conversation was created.                                                                                                                                   |
+| `id`         | string              | A unique identifier for the newly-created conversation. This can be used to associate the conversation with other events, or to make API calls targeting the conversation. |
+| `name`       | string              | The conversation's name.                                                                                                                                                   |
+| `deleted_at` | timestamp, optional | If set, the moment the conversation was deleted.                                                                                                                           |
 
-When a channel is deleted or expires, the `"created"` event is replaced with a tombstone
-`"created"` event, so that the original channel cannot be trivially recovered from the event stream. Tombstone events have a
-`deleted_at` field, and a `name` of `""`. Tombstone events for channels use an empty string as the name, and not
-`null` or with the `name` field removed entirely, to simplify client development. While clients
-_should_ treat deleted channels specially, for example by rendering them as "channel deleted" markers, they don't have to be - they make sense if interpreted as channels with empty names, too.
+When a conversation is deleted or expires, the `"created"` event is replaced with a tombstone
+`"created"` event, so that the original conversation cannot be trivially recovered from the event stream. Tombstone events have a `deleted_at` field, and a `name` of `""`. Tombstone events for conversation use an empty string as the name, and not `null` or with the `name` field removed entirely, to simplify client development. While clients _should_ treat deleted conversation specially, for example by rendering them as "conversation deleted" markers, they don't have to be - they make sense if interpreted as conversation with empty names, too.
 
-Once a deleted channel is [purged](./channels-messages.md#expiry-and-purging), these tombstone events are removed from the event stream.
+Once a deleted conversation is [purged](conversations-messages.md#expiry-and-purging), these tombstone events are removed from the event stream.
 
-### Channel deleted
+### Conversation deleted
 
 ```json
 {
-  "type": "channel",
+  "type": "conversation",
   "event": "deleted",
   "at": "2024-09-28T03:40:25.384318Z",
   "id": "C9876cyyz"
 }
 ```
 
-Sent whenever a channel is deleted or expires.
+Sent whenever a conversation is deleted or expires.
 
 These events have the `event` field set to `"deleted"`. They include the following additional fields:
 
-| Field | Type      | Description                         |
-| :---- | :-------- | :---------------------------------- |
-| `at`  | timestamp | The moment the channel was deleted. |
-| `id`  | string    | The deleted channel's ID.           |
+| Field | Type      | Description                              |
+| :---- | :-------- | :--------------------------------------- |
+| `at`  | timestamp | The moment the conversation was deleted. |
+| `id`  | string    | The deleted conversation's ID.           |
 
 ## Message events
 
-The following events describe changes to [messages](./channels-messages.md).
+The following events describe changes to [messages](conversations-messages.md).
 
 These events have the `type` field set to `"message"`.
 
@@ -203,7 +193,7 @@ These events have the `type` field set to `"message"`.
   "type": "message",
   "event": "sent",
   "at": "2024-09-27T23:19:10.208147Z",
-  "channel": "C9876cyyz",
+  "conversation": "C9876cyyz",
   "sender": "U1234abcd",
   "id": "M1312acab",
   "body": "an effusive blob of prose, condensed down to a single string"
@@ -214,22 +204,19 @@ Sent whenever a message is sent by a client.
 
 These events have the `event` field set to `"sent"`. They include the following additional fields:
 
-| Field        | Type                | Description                                                                                                                                   |
-| :----------- | :------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------- |
-| `at`         | timestamp           | The moment the message was sent.                                                                                                              |
-| `channel`    | string              | The ID of the channel the message was sent to.                                                                                                |
-| `sender`     | string              | The ID of the user that sent the message.                                                                                                     |
-| `id`         | string              | A unique identifier for the message. This can be used to associate the message with other events, or to make API calls targeting the message. |
-| `body`       | string              | The text of the message.                                                                                                                      |
-| `deleted_at` | timestamp, optional | If set, the moment the message was deleted.                                                                                                   |
-
-When a message is deleted or expires, the `"sent"` event is replaced with a tombstone
-`"sent"` event, so that the original message cannot be trivially recovered from the event stream. Tombstone events have a
-`deleted_at` field, and a `body` of `""`. Tombstone events for messages use an empty string as the `body`, and not
-`null` or with the `body` field removed entirely, to simplify client development. While clients
+| Field          | Type                | Description                                                                                                                                   |
+| :------------- | :------------------ | :-------------------------------------------------------------------------------------------------------------------------------------------- |
+| `at`           | timestamp           | The moment the message was sent.                                                                                                              |
+| `conversation` | string              | The ID of the conversation the message was sent to.                                                                                           |
+| `sender`       | string              | The ID of the user that sent the message.                                                                                                     |
+| `id`           | string              | A unique identifier for the message. This can be used to associate the message with other events, or to make API calls targeting the message. |
+| `body`         | string              | The text of the message.                                                                                                                      |
+| `deleted_at`   | timestamp, optional | If set, the moment the message was deleted.                                                                                                   |
+
+When a message is deleted or expires, the `"sent"` event is replaced with a tombstone `"sent"` event, so that the original message cannot be trivially recovered from the event stream. Tombstone events have a `deleted_at` field, and a `body` of `""`. Tombstone events for messages use an empty string as the `body`, and not `null` or with the `body` field removed entirely, to simplify client development. While clients
 _should_ treat deleted messages specially, for example by rendering them as "message deleted" markers, they don't have to be - they make sense if interpreted as messages with empty bodies, too.
 
-Once a deleted message is [purged](./channels-messages.md#expiry-and-purging), these tombstone events are removed from the event stream.
+Once a deleted message is [purged](conversations-messages.md#expiry-and-purging), these tombstone events are removed from the event stream.
 
 ### Message deleted