Every grant of access now has a reason

Minting a token, granting a role and revoking either can now carry a reason, and minting a token is recorded for the first time.

When an auditor opens the access list, the first question is why. Why does this token exist, and why does it hold this role? A state change in Smeldr could always carry a reason, and the reason was kept with the record. The acts that decide who may do anything at all had no such thing.

One of them left no record at all. Revoking a token or a grant wrote a history entry, but minting a token did not.

Four acts now take an optional reason: minting a token, revoking a token, granting a role and revoking a grant. Over MCP it is a reason argument on each tool, and on the command line it is --reason. The reason is stored on the act's history entry and read back when you list tokens and grants. It is trimmed and capped at a thousand characters. It is text people read, so it must never contain a token value or any other secret.

Minting is recorded now. The entry names the token by its fingerprint, never the token itself, and the actor is whoever minted it. When nobody did, because the first administrator token was created at first start or a program called the store outside a request, the actor is the mechanism, named as a job. A record never carries a silent empty actor.

Nothing is backfilled. A token or grant from before this release shows no reason, and the existing calls keep working unchanged.

A reason is optional, so the practical rule is yours: when someone asks later why a credential has a role, the answer is only there if the person who granted it wrote one.

Released in core v1.135.0, mcp v1.53.0 and cli v0.23.0.