Stop accepting new messages on deleted channels.

When a channel is deleted, Pilcrow should no longer allow new messages to be sent to it. This is part of the intended lifecycle of a channel, and either clients or the server may rely on it implicitly.

Steps to reproduce:

1. Create a channel:

    ```bash
    % curl \
        'http://[::1]:64209/api/channels' \
        --header 'cookie: identity=REDACTED' \
        --header 'content-type: application/json' \
        --data '{"name": "oh no"}'
    {"at":"2025-07-01T04:38:47.483235Z","id":"C2s1c6r1sc9921y3","name":"oh no"}
    ```

    Note its ID (here, `C2s1c6r1sc9921y3`).

2. Delete it:

    ```bash
    % curl \
        'http://[::1]:64209/api/channels/C2s1c6r1sc9921y3' \
        --header 'cookie: identity=REDACTED' \
        -XDELETE
    {"id":"C2s1c6r1sc9921y3"}
    ```

    Substitute the ID appropriately.

3. Send it a message:

    ```bash
    % curl -v \
        'http://[::1]:64209/api/channels/C2s1c6r1sc9921y3' \
        --header 'cookie: identity=REDACTED' \
        --header 'content-type: application/json' \
        --data '{"body": "oh very no"}'
    < HTTP/1.1 202 Accepted
    < […]
    {"at":"2025-07-01T04:39:23.658387Z","channel":"C2s1c6r1sc9921y3","sender":"L3twnpw918cftfkh","id":"Mhx9k6w3wxnk1f4t","body":"oh very no"}
    ```

    Substitute the ID appropriately here, as well.

What **does** happen is, as above, that the message is sent to the channel. It really is, too - you can see it in the ensuing event stream, or in boot. What **should** happen is that the API should reject the third request with an appropriate error - probably a 404. With this change, that's what happens:

```bash
% curl -v \
    'http://[::1]:64209/api/channels/C2s1c6r1sc9921y3' \
    --header 'cookie: identity=REDACTED' \
    --header 'content-type: application/json' \
    --data '{"body": "oh very no"}'
< HTTP/1.1 404 Not Found
< […]
channel C2s1c6r1sc9921y3 deleted
```

We had a test case that was intended to catch this. Unfortunately, I got a bit sloppy when writing it; instead of testing "can you send to a channel after deleting it," it was testing "can you send to a randomly-selected channel ID after deleting a channel" - which you can't, but not because of anything to do with deleting channels. The test case is now fixed, and does actually detect this issue.

This defect was not exercised by the client (and in practice probably affected nobody so far), so there are no client changes included. A client that tries this specific operation will get a 404, as above; this may happen if a user tries to send to a channel that is in the process of expiring at that moment, for example.

---

This change also proposes some changes to the conventions used for histories and for database access. It does not carry those changes through, so it introduces some inconsistencies, though I think they're minor.

* For histories: `Channel` histories now have an `as_of` method that takes an instant or a sequence number, and produces a snapshot of the channel at that point in history. It's used here to figure out what the state of the target channel is at the moment we're sending messages to it, but I think this might be more generally useful, as well.

* For database access: inserting a message now takes a `channel::Channel` (snapshot) instead of a `channel::History` as evidence that the caller has actually resolved the ID to an appropriate entity. This works in tandem with the `as_of` snapshot method, and I'm hoping this might help reduce our reliance on passing histories around to database methods if it generalizes well.

Merges send-to-deleted-channel into main.

0 files changed, 0 insertions, 0 deletions