Members can see their stack's governance changes #424

Problem

In a group stack, roster changes and grants are power exercised over members, and members can't see them. A member who only reads the _group Record can't read its journal (journal.md § Reading it), so additions, removals and new grants are invisible to the people they affect.

Opening the journal to readers isn't the fix. versioning.md § History access gates history on the mutate surface so that read access today never becomes access to the past. A curated projection isn't either: that rule's "publishing history is a projection" fits an author choosing which revisions to publish, but here the people making changes would be choosing what the affected people see.

Direction

A governance log, written by core:

• Every governance change gets an entry, written in the same write: each roster change on the stack's own roster (Design: a stack names its own roster #423) and each grant whose grantee is that roster. Admins can't skip or edit an entry.
• Members read entries from while they were members. Read access now doesn't grant the past, the same principle § History access protects, and someone who was removed or who left an at-risk group isn't exposed to people who joined later.
• It records writes only. It never logs the owner's reads: a log of who read what is surveillance infrastructure in its own right.

Limits to state in the spec

• It audits admins acting through Stack, not the key holder or the host. Anyone with full-trust access can rewrite or purge it.
• Tamper evidence would come from members keeping copies (for example, members storing the latest hash of a hash-chained log in their own stacks). That's a possible follow-up, not part of this issue.

Questions

• Do edits to the roster Record's own content (its name, its stackUrl) count as governance changes?
• Is the log a system type, or a projection of journal entries filtered to governance edges?

Order

Blocked by #423, which defines the stack's own roster.