muster release v5.19.11

Fixed

• Meta-tool calls no longer rebuild the session’s catalogue from the definition source and the capability store on every call (#1225). call_tool, describe_tool, filter_tools, list_tools and the resource/prompt meta-tools each listed the caller’s catalogue afresh: every workflow definition was fetched from the API server twice per call (once for the tool’s arguments, once to derive its read-only hint – 8182 GET workflows in the two minutes of one agent turn with 282 workflows), and every session-authenticated server’s capabilities were read from Valkey with their own HGET and GET (~160 round trips per call with 81 such servers). Together that was a floor of about 3 s per meta-tool call on a warm session while the backend answered in 22 ms. Now the aggregator’s own tools (core_*, workflow_<name>) are built once and kept until a workflow definition changes – through muster’s tools or, for a resource applied outside them, through the workflow reconciler – with the step tools carried on the tool so the read-only hint is derived in-process; a session’s capabilities are read with one HGETALL, and the content-addressed documents behind the references are decoded once per process and shared by every session that references them; the servers a session is authenticated to are read with one HKEYS. A warm meta-tool call costs two Valkey commands regardless of how many servers are registered. Toolset scoping, session-scoped visibility and the capability freshness mechanisms are unchanged.
• tools/call response and Error log lines carry duration_s, the time since the request reached the transport, so a slow call is visible in the log without subtracting the request line’s timestamp (#1225).