Push canonicalizes before verifying; other paths do not

`POST /push` verifies a signature against a canonicalized form of the payload, with object keys sorted recursively. Every other signature-verifying path in the server checks the bytes as received.

`rs/cyphr-storage/src/engine/mod.rs:881-882` runs `canonicalize_value` (`rs/cyphr-storage/src/import.rs:352-363`) before deriving the bytes the signature is checked against. `auth/login.rs:166`, `revoke.rs:111` and the witness-registration envelope at `routes.rs:713` all build their payload bytes with a plain serialization and no canonicalization step. There is no `canonicalize_value` call anywhere under `rs/cyphr-server/src/`.

The signature library does not sort — its canonicalization compacts while preserving field order — so this is the server's behaviour, not inherited.

## Why it matters

A client hand-building a payload signs what it built. For login and revoke that is correct. For push it fails, because the server checks different bytes, and the failure is a bare `protocol: invalid signature` with nothing indicating that key order was the problem.

The command-line client never encounters this: its transaction payloads happen to be constructed in alphabetical order already. Two tests carry comments noting their field order is deliberately alphabetical to match the sorting — so the requirement is known in the test suite and stated nowhere a client author would look.

The divergence may be entirely intentional. What it currently lacks is any statement of which endpoints sort and which do not, in a place a client author reads before signing something.

Read rs/cyphr-storage/src/engine/mod.rs, rs/cyphr-storage/src/import.rs, auth/login.rs, revoke.rs, and routes.rs to verify which payload bytes each endpoint signs. Find the client-facing documentation location, then document the canonicalization and field-order behavior for push, login, revoke, and witness registration; done means a client author can determine what to sign before using any endpoint.

Written by the indexing model from the issue text.