# `muse verify-commit --check-key-status` always reports "unknown" — hub endpoint doesn't exist

## Background

Discovered while recording *Build with Muse* episode 04, "Identity, Without
Passwords," right after confirming the musehub#96/#97 `--sign` fix worked
end-to-end. Not blocking for that episode (`valid: true` is the meaningful
field), but a real gap worth tracking.

```bash
muse verify-commit sha256:ecd4a78d... --check-key-status --json
# {"valid": true, "signer": "", "key_id": "sha256:2a7b8322...", "key_status": "unknown"}
```

`key_status` stays `"unknown"` even with `--check-key-status` passed
explicitly.

## Root cause

`muse/cli/commands/verify_commit.py::_fetch_key_status()` calls:

```
GET {hub_url}/api/keys/{key_id}/status
```

and swallows *any* exception (network error, non-200, bad JSON) into
`"unknown"`. Confirmed directly:

```bash
curl -sk -o /dev/null -w "%{http_code}\n" \
  https://localhost:1337/api/keys/sha256:2a7b8322.../status
# 404
```

The endpoint simply doesn't exist on MuseHub yet. This means
`--check-key-status` is currently a no-op for every commit, on every
repo, regardless of whether the underlying key is genuinely active or
revoked — the CLI flag exists and is documented, but has no server-side
implementation to back it.

## Scope

- Implement `GET /api/keys/{key_id}/status` on MuseHub, returning
  `{"status": "active" | "revoked"}` based on the key's registration state
  (see `muse auth key list/delete` — musehub#221 follow-up — for where key
  lifecycle state already lives).
- Confirm `_fetch_key_status()`'s timeout/error handling is still
  appropriate once the endpoint is real (right now every failure mode is
  indistinguishable from "hub doesn't have this feature").
- Add an integration test exercising `--check-key-status` against a real
  running MuseHub instance (not just the CLI-side unit tests, which
  presumably already mock this boundary — confirm and note where).

## Secondary, smaller finding from the same investigation

`signer` is also always empty (`""`) for human commits — traced to
`result["signer"] = commit.agent_id` in `_verify_one()`, which is
correct per the field's current documented definition ("agent_id string
from the commit record") but reads as broken/confusing for a human-signed
commit, since humans have no `agent_id`. Worth deciding, as part of this
same pass, whether `signer` should also surface a human handle when
`agent_id` is empty (e.g. resolved from the signer's registered identity),
or whether the field should stay agent-only and get a doc/UX clarification
instead so it doesn't read as a bug every time someone hits it.

## Acceptance criteria

- `muse verify-commit --check-key-status` returns `"active"` for a
  genuinely active key and `"revoked"` for a genuinely revoked one against
  a real MuseHub instance (staging), not just `"unknown"` universally.
- A decision made and implemented (or explicitly deferred with a filed
  follow-up) on the `signer` field for human commits.