Sessions outlive the deploy that interrupted them

A MemoryStore meant every restart signed out every desk on the site
being deployed. Bearable while a desk is three people, and not the
kind of thing that gets better on its own.

They live in NATS KV now: the JetStream already under the events, the
projections, the content reload and the access questions. No new
service, no new store, and the same bucket a second instance of a site
would read if there ever is one. `create` draws a fresh id rather than
writing over a session already at that key, the bucket's `max_age`
collects what nobody comes back for, and a record's own expiry is what
answers a load, whatever the bucket still holds.

Proved the only way it can be: a store opened twice against one
JetStream, which is what two runs of the binary are.

Also fixed, while there: the integration test asserted a record's
projected state was one that `aggregates::transition` never writes -
it appends events, the desk handler updates the projection - so it
failed whenever it was actually run. It now asserts what it says it
does, that a mailed reply leaves the state alone. test.yml has been
red since 0.3.47 while publish.yml stayed green, which is how v0.4.0
went out over it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/architecture.md

@@ -85,3 +85,8 @@ their graphs with no bespoke UI per bucket.
 - `iris` — the lint, from its own repo, shipped in every release
   tarball so a content repo's CI can lint with the exact version its
   instance runs.
+
+**Sessions** (`src/sessions.rs`) — in the same JetStream KV as
+everything else, so a restart does not sign anybody out. The bucket
+carries a `max_age` so NATS collects what nobody comes back for, and
+each record's own `expiry_date` is what decides on the way out.