Verify is not just true or false, granular outcomes on /verify

Until last week the public verify endpoint at GET /api/v1/verify/{signature_id} returned a single boolean: {verified: true} or {verified: false}. That works for the buyer's first-glance UX. It does not work for a regulator or a court trying to figure out what actually went wrong.

An older trust-data-infrastructure design we read for context lays this out: their verify can return Valid Document, Invalid Signature, Incorrect Hash, Invalid Receiver Public Key, or Valid Document (Adulteration Not Detected). Each label is a different forensic story. Invalid Receiver Public Key means substitution or man-in-the-middle. Incorrect Hash means transit corruption. Invalid Signature means key compromise.

A boolean cannot carry that.

What we added

{
  "verified": true,
  "verification_detail": {
    "signer_key_match": true,
    "signature_valid": true,
    "algorithm_match": true,
    "agent_active": true,
    "validation_label": "valid"
  }
}

Four sub-checks plus a stable label. The label resolves to one of: valid, invalid_signature, signer_key_changed, algorithm_mismatch, agent_inactive, agent_unknown.

The field is optional. Older clients that do not know about it ignore it. New clients render the per-axis breakdown. Backwards-compatible by construction.

The public verify HTML at asqav.com/verify/<signature_id> got a small grid below the existing fields, conditional on the API returning the detail.

What this is for

A regulator asks: when did this signature go bad? Was it the day the key was rotated? You want a label, not a bool.

A court admissibility question: was this record signed by the agent the policy claims signed it, or by something with a different public key? You want signer_key_match as its own line.

PR with the diff: github.com/jagmarques/asqav#141