muster release v5.29.0

The tool list follows a backend redeployed behind its Service. A server’s tools were read at registration and again only when the server sent notifications/tools/list_changed or its definition changed. A backend rolled to an image with another tool set does neither: the new process has never seen muster’s session, so it notifies nobody, and the session recovery and the health probe heal the connection without re-reading the tools. The old list stayed until a restart – a tool the new image dropped kept failing with tool not found, a tool it added stayed invisible. The aggregator now re-lists every connected server every MUSTER_AGGREGATOR_CAPABILITY_POLL_INTERVAL (default 5m) and updates what changed, through the same refresh and the same notifications to clients as after a list_changed: a server with a shared client once, a server served per session through each session’s own live connection into that session’s list. Nothing is polled that is not connected, a listing that fails leaves the cached list as it is, and the log names the trigger (Capability refresh (poll): updated 3 tools for <server>). The harness’s test_redeploy_mock_server gained add_tools and remove_tools – a new image with another tool set, announced to nobody – and two scenarios roll a backend that way and see the poll re-list it on the production schedule, for a shared connection and for a signed-in session’s pooled one. (#494)