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.

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:

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.