muster release v5.20.0

muster test: scenarios can run their instance on Valkey storage and restart it. pre_configuration.storage: {type: valkey} starts an in-process Valkey stand-in (miniredis) per instance and points every backed store – session auth, capabilities, OAuth tokens, state, client credentials, the OAuth server’s own store – at it, the way an installation’s stores outlive a pod; start_delay makes it answer only after muster serve started, for “Valkey is late” scenarios. test_restart_instance stops and starts muster serve on the same configuration while the store and the mock servers keep running and reconnects every user client with the bearer it held, so the steps after it act as the sessions that lived through a rollout; test_stop_valkey / test_start_valkey take the store away and bring it back with its data. Three scenarios reproduce bugs that were first seen on an installation because the suite could not express them: a family tool call after a restart without a listing (fails on v5.18.2, #1204), a Valkey that answers late at start being waited for rather than replaced by memory stores (fails on v5.19.12, #1229), and a pinned bare-401 server staying connectable and its grant revocable after a restart with no login in the new process (fails on v5.8.3, #1150, #1154). (#1236)

The DPoP replay cache’s Valkey client no longer enables valkey-go’s client-side cache: nothing reads through it, and its CLIENT TRACKING handshake failed against a server without the feature, which left muster’s OAuth server in degraded mode (service_unavailable on every request). The session stores and the mcp-oauth store already ran without it since v5.19.13.