anthropic: adds a schema pre-processor for compatibility.

[absoludity]

When hooking the anthropic knowledge service up with the public beta structured output support, I hit a bunch of issues for unsupported schema elements.

Their documentation lists the JSON Schema limitations but as you'll see from the diff here, it's not limited to those limitations :/

When running with structured outputs with our DPP schema, this code is some of what is required for preprocessing the schema. I'm still not finished... note to self: current error is requiring the next preprocessing step is:

julee-rba-worker-1  | temporalio.exceptions.ApplicationError: BadRequestError: Error code: 400 - {'type': 'error', 'error': {'type': 'invalid_request_error', 'message': "For 'string' type, format 'binary' is not supported"}, 'request_id': 'req_011CXbBgjLvvbB4BfBHsjQMw'}

I will try to complete this pre-processor, but the bigger the preprocessing change, the less useful the structured output is for us I think.

This PR isolates just the preprocessor... I have a following branch which then uses this to use the structured output, which I'll push once this preprocessor is allowing the query to succeed.

Ref #60

[absoludity]

Closing this PR for now, since even with the preprocessed schema, we end up getting the following error from anthropic:

{
  'type': 'error', 
  'error': {
    'type': 'invalid_request_error', 
    'message': 'The compiled grammar is too large, which would cause performance issues. Simplify your tool schemas or reduce the number of strict tools.'
  }
}

Trying another approach which keeps the schema with the original request prompt but uses a basic structured output schema just to ensure we get json back.

[absoludity]

Trying another approach which keeps the schema with the original request prompt but uses a basic structured output schema just to ensure we get json back.

Re-opening since the above won't work (anthropic only returns data from the schema, and explicitly ensures additionalProperties is False). So the next path to try is to break the query up into smaller queries (which will have smaller schemas, but I'm guessing that it will still be too large.