Adding "constraints" to string validation (enum, pattern)

[colleenXu]

[For post-2.0]

We could add more "constraints" to string fields to flesh out, standardize, or add detail to their implementation. This would also add more stringent validation.

I previously reviewed the entire schema (2026-02-07, probably branch 2.0) and came up with this (copied, cleaned up #538 (comment)):

Add enum to...

• statuses:
  • AsyncQueryResponse.status
  • AsyncQueryStatusResponse.status
  • Response.status
  • LogEntry.code
• knowledge_type: lookup or inferred (aka creative-mode)
  • QEdge.knowledge_type
  • MetaEdge.knowledge_types.items

Add `pattern` to...

• URLs (similar to AsyncQuery.callback's pattern):
  • AsyncQueryStatusResponse.response_url
  • Attribute.value_url
  • RetrievalSource.source_record_urls.items
• semantic-version
  • Response.schema_version
  • Response.biolink_version
• LogEntry.timestamp
• biolink terms only?
  • MetaQualifier.qualifier_type_id (could use Qualifier's)
  • Attribute.attribute_type_id
  • MetaAttribute.attribute_type_id
  • AttributeConstraint.id

Add infores `pattern` to source IDs?

Source-related fields.

• RetrievalSource.resource_id
• RetrievalSource.upstream_resource_ids.items
• Analysis.resource_id
• QEdgeConstraints.sources.values
• Attribute.attribute_source
• MetaAttribute.attribute_source

[colleenXu]

Note: there is an old PR https://github.com/NCATSTranslator/ReasonerAPI/pull/406/changes but it may have issues...

The json-schema regex flavor doesn't allow many shortcuts - so ^\S+:\S+$ wouldn't be allowed (what about openapi's regex flavor?)