Say in the schema what a verified date records

[haruotsu]

verified was the one field in the connection schema with no description,
and it is the field that most needs one: every other key changes what gete
does, while this one changes nothing at all. Nothing reads it beyond
gete connections, which prints the date or not verified in Gemini Enterprise.

So a reader meeting verified: {gemini_enterprise: 2026-08-27} in a catalog
entry has nothing to tell them how much of the flow that date stands for, or
that no check is being made against it.

"verified": {
  "description": "Where an authorization through this connection has been taken end to end and seen to work. Nothing follows from it: gete checks nothing against it and behaves no differently, but `gete connections` prints it, so a reader can tell what was observed from what a provider's metadata merely promises.",
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "gemini_enterprise": {
      "description": "The date an authorization was taken through Gemini Enterprise: consent screen, code exchange, and the token used against the service. Absent until one has been.",
      "type": "string",
      "format": "date"
    }
  }
}

The date's meaning is the part worth pinning down: consent screen, code
exchange, and the token used against the service. That is what the entries
carrying one were held to, and stating it keeps a later entry from claiming
the word for less.

Text only - the accepted shape is unchanged, and a document that validated
before validates now. Other properties in this schema and the others are
still undescribed; they are left for whoever needs them.

tests

tests/test_schema.py: the connection schema is expected to describe
verified and the date under it. Written first, red, then the schema.