Function render_diagnostics 

pub fn render_diagnostics<'a>(
    id: &'static str,
    pairs: impl IntoIterator<Item = (&'a str, &'a str)>,
) -> String

Render a set of field-level diagnostics as one user-facing block.

The single renderer for validation refusals. Both validation services use it, so tix link and tix parent set report refusals in the same format and a user who learned one does not have to learn the other. It lives here rather than in either service because neither owns the other’s diagnostics, and a second copy of this loop is how the two formats drift apart.

id names the surface (E-tix-link, E-tix-hierarchy, …); it is passed in because only the caller knows which command is refusing. Rendering is delegated to crate::diagnostics, so a refusal here and a tix lint finding there are the same rustc-style block.

Three properties, each of which a service message made necessary:

• Every diagnostic is reported, not just the first. A rejection can carry several, and showing one at a time makes a user fix and retry repeatedly to discover the rest.
• The kind is prefixed unless the message already names it. Several service messages do (cycle: 1 -> 2 -> 1), and prefixing unconditionally produced the doubled, stuttering cycle: cycle: ....
• Duplicates are collapsed. A self-link is reported by the self-link rule and again by the cycle rule, so without this the most common rejection printed the identical sentence twice. Collapsing is presentation, and leaves the diagnostic set the service produced intact for any other consumer.