Receipt/tip root-set is carried by three separately-shaped types

The same four-field root set (principal root, state root, auth root, commit root) is carried by three independently-defined shapes: `receipt::Roots`, `routes::PushRoots`, and the tip response's flat top-level fields. They agree today only by convention, not by a shared type — if the underlying root set ever gains, loses, or renames a field, nothing forces all three call sites to be updated together, and they could silently drift apart.

Separately, `rs/cyphr-server/src/auth/principal.rs` hand-rolls canonical-payload key-sorting and coz wire-blob assembly for the server's own chain construction, shadowing logic that already exists in the core `cyphr` crate rather than reusing it — the same "duplicates internal tree-building logic" pattern already noted as a maintenance risk in `docs/specs/proof-portability.md` for a different reason, recurring here.

Both are candidates for a later consolidation pass: one shared root-set type used everywhere, and routing the server's chain-construction logic through the core crate's own primitives instead of re-deriving them.

Part of the server production-readiness effort tracked in #23. Discovered during the work tracked in #88.

Start by comparing receipt::Roots, routes::PushRoots, the tip response fields, and rs/cyphr-server/src/auth/principal.rs with the core cyphr crate primitives. The consolidation is done when one shared root-set type is used across the receipt, routing, and tip paths, and server chain construction reuses the core crate instead of duplicating sorting and wire-blob assembly logic.

Written by the indexing model from the issue text.