Spec: state who governs a group stack, and what removal takes away #419

Problem

identity.md § Group describes the roster's member and admin roles in detail, but not where they sit relative to the stack's owner:

• The owner of a group stack is whoever holds the group's key, and the owner's access is unconditional: there is no Record in the stack they may not read, and they can manage any Group regardless of roster. The roster's admin manages the roster; it doesn't bound the owner.
• The owner's reads are not recorded anywhere. The journal records writes only.
• Removal cuts a member's reach to what they wrote. Authorship confers no read: a member reaches Records through record-level permissions or type grants, and a group grant stops reaching them once they're off the roster. createdBy still names them. A member who wants their contributions copies them out while still a member; a group that wants a gentler exit grants the person individual read before removing them.

All three follow from existing rules, but a reader has to assemble them. They're defaults that matter to anyone deciding whether to join a group stack, so the spec should say them.

One edge is unpinned: resharing is allowed for the owner or the Record's creator (access-control.md § The write bit: a recoverability trust model). It's not tested whether a removed creator keeps reshare authority on a Record they can no longer reach.

Actions

• Test first: a creator removed from the roster that conveyed their access can neither read nor reshare their Record. If the reshare succeeds, fix it in ScopedStack (a Bug, with a patch changeset for @haverstack/core).
• Spec, identity.md § Group: the three points above, linking access-control.md for owner authority and journal.md § Reading it.
• No changeset for the spec change alone.