fix(acp): follow channel membership changes at runtime

[LiterallyBlah]

Summary

• treat relay membership as authoritative by default while retaining configured channels as startup seeds
• subscribe and unsubscribe running ACP agents on kind 44100 / 44101 without a restart
• preserve an explicit fixed-scope opt-out, including immutable startup snapshots and empty explicit scopes
• reconcile membership across reconnects, setup/listener mode, failed authority lookups, equal-second events and channel-specific relay closure
• reject malformed or wrongly targeted membership notifications before replay/deduplication state changes

Buzz issue root: 46cebe91d0ad7b7ac26e177afa57197ddb682eac02e042d2160640dc126f3abb

Verification

• cargo fmt --check
• cargo check -p buzz-acp
• cargo test -p buzz-acp — 753 passed
• cargo clippy -p buzz-acp --all-targets -- -D warnings
• cargo build -p buzz-acp --release
• git diff --check
• independent exact-diff review: PASS

Runtime acceptance

Deployment and live no-restart membership add/remove proof will be attached to the originating Buzz issue after rollout.

[ScaleLeanChris]

Field-tested the runtime membership path with a real Hermes identity on an authorized private relay and channel. I stacked #5582 locally because stock hermes-acp otherwise fails before the subscription test begins.

One buzz-acp process remained alive for the complete sequence:

1. Initial authorized prompt reached Hermes.
2. Removing the agent from the channel produced channel access denied by relay: restricted: channel access revoked; dropping subscription, keeping connection.
3. A prompt published while removed was not dispatched to Hermes.
4. Re-adding the same identity restored delivery. Hermes received and completed a new prompt without a process restart.

Focused membership suite: 10 passed, 0 failed.

This gives direct coverage of both fail-closed removal and live re-add. It also confirms that the connection remains healthy while the revoked channel subscription is dropped.