A keyed witness signs responses and publishes no key to verify them

A server started in witness mode with a signing key configured signs its responses while refusing to publish the key that signed them. A client receives a signed statement it cannot verify and has no way to obtain the key through the discovery endpoint.

## Reproduction

Start a witness with `--signing-key-path` set:

```
GET /server -> {"v":1,"payload":{"tier":"witness","mode":"witness","now":…},
"statement":{"kind":"unsigned"}}

GET /tip -> "statement": {"kind":"signed"}
```

No `pub`, no `pg`, and a signed tip.

## Cause

`identity()` in `rs/cyphr-server/src/routes.rs` branches on the mode being `Witness` before it consults `AppState::attestor()`, so a witness publishes its tier and no key material whether or not a signing key is configured. Meanwhile `serve()` bootstraps a server principal whenever a signing key path is set — it does not check the mode — and `sign_tip_attestation` asks only `attestor_identity()`.

The two paths disagree about whether a witness has an identity.

## Why it matters

Signing is only useful if a verifier can find the key. This configuration produces signatures nobody can check, and it does so silently — the server starts normally and serves both endpoints without complaint.

Either the witness tier should carry identity fields when a signing key exists, or a keyed witness should refuse to sign. The current pairing is the one combination that helps nobody.

Start in rs/cyphr-server/src/routes.rs with identity(), then trace serve() and sign_tip_attestation to compare identity publication with signing-key initialization. Reproduce the keyed-witness responses for /server and /tip, then determine and test the intended behavior: publish verifiable identity fields or refuse to sign when running as a witness.

Written by the indexing model from the issue text.