In-memory Noizu.MCP.Auth.Server.Store adapter.

For development, for tests, and for a single-replica deployment that can afford to lose OAuth state on restart (losing it costs a re-login, not data). Not clustered — each node would hold its own codes, and a token request that landed on the wrong node would fail.

Why a GenServer

Reads go straight to ETS. Every mutation goes through the owning process, and that serialization is what makes take_authorization_code/2 and rotate_refresh_token/3 genuinely atomic: two concurrent redemptions of one code are two messages in one mailbox, and the second sees used_at already set. Doing it with bare ETS would need a compare-and-swap per operation; a mailbox is simpler and, at authorization-code volumes, indistinguishable in cost.

children = [
  {Noizu.MCP.Auth.Server.Store.ETS, name: MyApp.MCPOAuthStore}
]

store: {Noizu.MCP.Auth.Server.Store.ETS, name: MyApp.MCPOAuthStore}

Hashing follows the behaviour: raw credentials in, Secret.token_hash/1 keys stored. An in-memory store has no attacker-readable table, but a heap dump and a crash log are both real, and an adapter that stores plaintext here would teach the wrong shape to whoever copies it.