muster release v5.29.2

muster agent --mcp-server no longer loses a tool’s answer behind a notification. The bridge opens no standalone GET stream, so every notification the aggregator sends its session – notifications/tools/list_changed as SSO connections are established at connect, as the person’s session connects further servers, as a backend re-lists – is written onto the response stream of the call_tool in flight, ahead of the result. The bridge’s transport handed each one to Client.NotificationChan with a blocking send on the goroutine that reads that stream; the channel holds ten and nothing read it in this mode, so the eleventh notification of the process’s life stopped the reader in front of the call’s result and the call ended in the bridge’s timeout (Meta-tool execution failed: tool call failed: transport error: context deadline exceeded) while the aggregator had answered in seconds – giantswarm-platform-manager’s platformctl installation verify lost the live half of every verify of the hub that way. The hand-off never waits now (a notification the queue has no room for is dropped and logged; a list_changed is a signal to re-list, one queued stands for all that follow), and in --mcp-server mode the bridge reads the queue, lets its caches follow a list_changed and relays the aggregator’s list_changed notifications to the assistant as its own, which its tools.listChanged capability promised – after the pending-auth upgrade too. (#1309)