If it's machine readable, should we use an typedef'd string here instead of a raw string?

Yeah, depends on how many we want to spec. I was potentially anticipating hundreds - with components mostly responsible for sending them in the case where there is a clear API subtlety in the error that a client could react to with a more appropriate message. I.e. if the Details says "pod 0294830298420394804 not found" and the Reason is "not_found_pod", a client can choose to say:

switch status.Reason {
case "not_found_pod": 
   msg = "The requested pod could not be found.  It may have been deleted."
default:
   msg = "Unable to complete request: " + status.Details
}

In a sense, I'd say this is almost exactly like Golang "error" in practice - you can do a string.Contains() for a specific segment (if the stdlib doesn't give you a type) but in most cases you prefer to do an equality check to a constant, a type cast to a struct, or an interface type cast.

I feel like this will evolve into a complicated mess, and arguably I started it with the poorly defined "Details" field. I'd argue for making a system where there are two fields. One is a machine readable string enum (of which "other" is one of the choices) and the other is something like the current details field. I think whatever system you use, you should replace the Details field. It's only used for one thing right now, so now is the time to fix it.

{
  "status": "Working",
  "detailType": "OperationNumber",
  "detail": "42",
}