Woops, I see. Another thing that would work is using this query instead extra_data__contains=f'"client": "{client}"' (querying for the key and value pair instead of the dictionary as a whole). However, I can see that these types of queries have a dependency on our DjbletsJSONEncoder. Our DjbletsJSONEncoder (which encodes the data for our JSONFields) uses : to separate keys and values, but if we were to ever change that (for example to : with no space), then the query would break. It seems unlikely that we would ever change that, but still something to think about.
I'm leaning towards avoiding adding a new field. I think the above solution would work well, I've added a unit test for it and tested it out manually with tokens that have multiple things in their extra_data. What do you think? Also, is it ok to warrant a database upgrade for point releases, or is this something that should only happen for major releases?

__contains on an extra_data can be very slow. The database has to read the contents of every single field and do a string search, and depending on how it decides to do this, the result can be a full table scan. We want to avoid those wherever possible. On top of this, the above query will match:

{
  "extension-provided key": {
    "client": "foo"
  }
}


Instead, a faster and safer way to accomplish this is by handling matching on the Python side. We query all tokens for the user and then check within extra_data for the matching value.
I think that's fast enough. Most users will only have a handful of tokens, so this won't add any noticeable overhead. Plus we're only using this during a login flow, not per-request or anything.
Since this is informational, I think we're okay using extra_data and just doing this sort of lookup this way. If we needed to filter based off the field per-request or something, I'd say we introduce one in RB6. But I don't see us needing to do that for anything currently planned.