fix(acp): reconcile channel memberships

[samiriasbeck]

Summary

• expose authenticated channel discovery on the reusable REST client
• periodically compare memberships with active subscriptions
• subscribe missing channels without restarting the harness
• keep reconciliation additive; removals still require membership notifications
• allow the interval to be configured with BUZZ_ACP_CHANNEL_RECONCILE_SECS (30-second default, 5-second minimum)

Why

Membership notifications can be missed during reconnect. Without reconciliation, direct messages or groups created after startup can remain unavailable until the harness restarts.

Safety

A stale or partial REST response never removes subscriptions. Notifications remain the authoritative path for membership removals.

Tests

• stable channel identity and missing-subscription coverage
• cargo test -p buzz-acp
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• just ci

[Silentpartnercoding]

channel_memberships_to_reconcile only adds memberships. I think that leaves a revocation gap at the exact failure mode this PR is meant to repair: if the harness reconnects after missing a removal notification, discovered no longer contains channel C, but C remains in subscribed_channel_ids and the relay subscription stays live indefinitely. A partial snapshot must not revoke access, but treating every omission as non-authoritative means periodic reconciliation can recover grants and never recover revocations.

Could the REST discovery expose an explicit complete/fresh snapshot boundary (or current membership heads) and diff subscriptions only when that proof is present? Rebuilding subscriptions from a complete authenticated snapshot on reconnect would also preserve the boundary.

A regression where removal happens while the WebSocket is down, the removal event is not replayed, and the next complete snapshot omits C should assert C is unsubscribed before any C event reaches the agent. A partial or failed snapshot should keep the existing subscription.