Cross-witness equivocation detection cannot run in a deployed server

`check_cross_witness_consistency` in `rs/cyphr-server/src/consistency.rs` has no production caller, and no code path anywhere assembles the input it consumes. Cross-witness equivocation detection is fully implemented and fully tested, and cannot run in a deployed server.

## Evidence

Call-graph tracing returns no callers for the function. The same tool returns 47 real callers for `build_router` in the same crate, so the empty result is a genuine absence rather than an unresolved query. A text search over the whole tree agrees, and the two instruments are independent.

All eleven registered routes were traced from `build_router` inward; none reaches `consistency.rs`. No other workspace crate depends on `cyphr-server`, and the server binary — the sole production entrypoint — never references the module, so the `pub` visibility has no crate boundary to be meaningful across. Both the strict reading (dead code) and the permissive one (no in-tree caller) give the same answer.

It was never wired. A history search across all branches shows the function was introduced already-unreachable and never had a production call site added or removed. This is unfinished work, not a regression.

## The root cause is upstream of the function

Nothing collects tip reports from more than one witness into a place where they could be compared. The sync path is a single witness-to-authority pair. Fanout is one-way push. There is no polling loop. So even given a caller, the comparison would have no input.

Gossip — the mechanism intended to produce that input — is not specified as a protocol section. The working copy of `SPEC.md` carries a §13.7 "Gossip" marked `// TODO` describing only client-side behavior, but that section does not exist on the `zami` branch where the specification is maintained; there, gossip is mentioned within the consensus section and is never formalized. Either way there is no server endpoint and no participant responsible for assembling multi-witness state — and the absence is more complete than a placeholder implies.

## Why this is a design item rather than a fix

The missing piece is a *role*, not a call site: something must assemble reports from more than one witness so they can be compared. Gossip is one way to fill that role. A registry poll is another. An operator-driven audit is a third. They imply different topologies, different liveness properties, and different parties a deployer must trust, and nothing currently in the repository decides between them.

Adding a caller without settling that would wire the detector to whichever mechanism was convenient and bake a deployment assumption into the layer least able to revise it. The related question of whether the specification should name a mechanism at all, or name the role and let a deployment choose its filling, belongs with the specification.

This is the same shape as #154, which is why the two are best treated together: in both cases a mechanism exists and the participant that would give it meaning does not.

## Consequence for the current tree

`consistency.rs` is correct, tested, and inert. It should not be read as an active defense. Anything relying on equivocation being detected server-side is relying on a mechanism that does not execute.

There is also a related defect confined to this module: the evidence document built in the `Proven` branch reads its principal and sequence fields from raw JSON values rather than the canonical typed report, so a witness legitimately signing a sequence as a string would produce evidence with a non-canonical field. It is not a live trust path today precisely because the function does not run, and it should be fixed as part of whatever wires this up rather than separately.

Read rs/cyphr-server/src/consistency.rs and trace build_router and the server binary to confirm the detector has no production path. Review SPEC.md §13.7 on the working copy and the consensus section on the zami branch, then decide what participant or protocol role should assemble reports from multiple witnesses. Done means the design is specified and the detector has a deliberate, tested deployment path, including the noted evidence-field defect.

Written by the indexing model from the issue text.