Server key-rotation path has no caller in the shipped binary

`AppState::rotate_signing_key` (and the `ServerPrincipal::rotate` it wraps) is a fully tested library capability — including a deliberately non-atomic chain-then-keyfile crash-window protocol with its own hazard documentation — but nothing in the shipped server binary or CLI ever calls it. It's reachable only from tests.

This isn't a defect on its own (rotation as a tested-but-unwired capability is a reasonable place to land pre-1.0), but it's a landmine for whoever wires a live rotation trigger later: they must also make sure the server's in-memory signing identity gets refreshed after rotation, or the server keeps signing with the retired key until its next restart. There are also two different rotation entry points in the codebase today with different safety properties, which whoever wires this up needs to reconcile deliberately rather than pick the wrong one by accident.

Worth a tracked reminder so the crash-window hazard comment and the two-entry-point situation get read carefully whenever this capability actually gets a caller.

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

Start at AppState::rotate_signing_key and the ServerPrincipal::rotate entry point, then inspect how the shipped server binary and CLI expose server operations. When this capability gets a caller, reconcile the two rotation paths, account for the in-memory signing identity refresh, and preserve the documented crash-window behavior.

Written by the indexing model from the issue text.