feat(base,app,learn): a shared space's key rolls once a member goes

What is written in a shared space after a member went takes a key they
never get (Halkyon's ADR 0044, D22). The instance marks the space as one
of its members goes, removed, leaving or deleted (`keyRollDue` on
`shared_space`, set in `removeMember`, through which each of them
passes); an invitation taken back never had a key and marks nothing, nor
does a new role. The Owner's or an Editor's device that next keeps its
keys up after a sync is told so (`sharedSpaceKeys.rollDue`, never true
for a Viewer, who seals no key) and makes a new key, sealed to those who
stay (D33). The first seal bringing a key ID the space never had clears
the mark in the same transaction (D34); members the rolling device
missed get it later as newcomers do. Earlier rows keep the key they had,
which whoever went had read already.

The migration, the same in the module and in each server including it
(Learn, Meditate, Todo, Train):

  ALTER TABLE "shared_space"
    ADD COLUMN "keyRollDue" boolean NOT NULL DEFAULT false;

It adds the column with false for every space there is, so no space is
due a roll from it; PostgreSQL adds a column with a constant default
without rewriting the table. The server before the switch reads and
writes the table naming its own columns, so it keeps working.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>

docs/adr/0044-shared-spaces-and-collaboration.md

@@ -179,6 +179,16 @@ member reads everything in the space.
   *Mark as compared*; a member whose keys changed is flagged on their row, and their
   new keys are trusted on that screen, after comparing. Members are matched to their
   keys by handle, as the member list names nobody by account ID.
+- **D33.** **A writer's device rolls the key at its next upkeep** (decided 11 Nov 2026,
+  the agent's recommendation, reading D22): the instance marks a space whose member
+  went (removed, left or deleted; an invitation taken back never had a key), and the
+  Owner's or an Editor's device that next keeps its keys up after a sync makes the new
+  key and seals it to the members. Two devices rolling at once make two keys, both
+  sealed to everyone, the later one taken: harmless.
+- **D34.** **A new key sealed clears the mark** (decided 11 Nov 2026, the agent's
+  recommendation): the first seal bringing a key ID the space never had, in the same
+  transaction. Members the rolling device missed (keys changed, not trusted anew) get
+  it later as newcomers do; waiting for every member would roll again and again.
 
 ## Steps
 
@@ -197,6 +207,10 @@ member reads everything in the space.
    on first sight (`KeyPins`), with the safety code of halkyon_keys (`safetyCode`).
 4. **Learn shares a studyset** (D14, D20 to D26): the copy, *Manage collaborators* (invite by
    @handle, the members, their roles, leaving), each member's own reviews.
+   Built 11 Nov 2026 (D27 to D34): the copy into a space of its own, the Share sheet
+   with its members, roles, leaving and safety codes, a Viewer's screens read-only,
+   and the key rolled once a member goes. Left: a Viewer's per-item buttons inside the
+   material tabs, and a message for a write the engine refuses them.
 5. **Invitations by email and by link** (D4, D5), the Inbox.
 6. **Agents** (D6, D7, D10, D12).