Make the 'access log' whole and useful

[gkc]

Is your feature request related to a problem? Please describe.

It's a legacy appendage right now, unused

Describe the solution you'd like

Scope it correctly, and make it useful

Describe alternatives you've considered

No response

Additional context

No response

[cconstab]

With the new Enroll Update verb we need to record the rotations and report on them.

This out of band mechanism might be the right place to collect and then send events to the owner of the Atsign or group of Atsigns..

[gkc]

Whatever gets built here should absorb the enrollment revocation history, rather than leaving two audit trails side by side.

It already exists, and it is richer than the access log. Every moment an enrollment's revocation state changes is written as its own at-rest record under <eventId>.revocation.events.__manage@, defined by EnrollmentRevocationEvent in packages/at_secondary_server/lib/src/enroll/. Three kinds today — revoked, unrevoked and superseded, the last being a retrofit predecessor retired when its successor first authenticates. Each event carries the enrollment whose state changed, the moment, the namespace grants it held at that moment, the enrollment on the connection that issued the command, and the enrollment a cascade started from.

The reason to fold it in is that all of that currently feeds one scalar. The only reader is enroll:infons:<namespace>, which nets the events down to a single lastRevokedAt. Nothing can ask who revoked what, when, or on whose authority, even though the records hold the answer. That is the same gap this issue describes for the access log, arrived at from the other direction: the access log is scoped wrongly and read by nobody, while the revocation history is scoped well and exposed almost nowhere.

It also fits the rotation reporting in the comment above. Revocation, supersession and an enroll:update rotation are the same kind of fact about an enrollment's life, and they want one home and one query surface.

Two constraints worth designing against rather than discovering:

⚠️ Retention cannot be uniform. AtAccessLog implements Compactable, so access entries are prunable by design. The revocation history is not: lastRevokedAt nets out un-revocations, so dropping old events silently changes the answer a client already reads, and that answer can move backwards on its own. If the two share a store, retention has to be per event kind, and the enrollment events are the ones that must survive.

⚠️ The current entry shape will not carry these. An access entry is an atSign, a verb name, an optional lookup key and a time. An enrollment event has a subject and an actor that differ, plus a cascade origin and a grant set. Widening the entry is part of the work, not a detail after it.

Worth noting the grants are recorded per event on purpose: a revoked enrollment's own grants at that moment, never its approver's, which is what lets a namespace question be answered from the history alone.