Design: a stack names its own roster #423

Problem

A collaborative group is a _group Record in someone's personal stack whose stackUrl points at the group's own stack (identity.md § Group). Inside that group stack, the only role core knows is the owner, _config.entityId. Nothing records who the stack's members and admins are:

• A roster inside the group stack would be one more _group Record, indistinguishable from any other list kept there.
• So one group has two rosters, one in the founder's personal stack and one in its own, with nothing keeping them in step. Core doesn't resolve a roster across stacks (access-control.md § Known limitation).
• "Admin of the stack" therefore means "holds the key". The roster's admin role and the owner's authority are different things, and only the first is written down.

Direction

_config names one _group Record in the stack as the stack's own roster:

• That roster is authoritative. The group owns its own membership; a _group with a stackUrl in a personal stack is a pointer to it.
• Its admins manage membership without holding owner authority, which makes the split between key holders and administrators visible.
• The other _group Records in a stack stay the owner's own lists, with today's rules.

Questions

• How does the designation interact with "who may act as the Group" from Design: key lifecycle (custody, recovery, rotation, and acting as a Group) #422? Are the roster's admins the ones a delegation names?
• _config is protected and every adapter excludes it from queries. What does adding a field cost in conformance fixtures and the wire format?
• Can the designation change, and who may change it?

Order

Blocked by #422.