Approve the current draft ontology for use by graph ingestion

Approve the current draft, making it the ontology GraphService uses for this project.

Checked against the project's already-registered ontology before approval: a project that has never ingested anything always succeeds; one that has fails with a 409 only if the draft retypes a property FalkorDB's OntologyStore already froze for this project — that's the one change that can leave previously ingested data inconsistent with the new schema. A new entity/relation label, a new property, or a new relation pattern on an already-registered label are all safe additive changes: they're force-applied directly into FalkorDB via GraphService.override_registered_ontology, bypassing OntologyStore.register()'s stricter-than-necessary subset rule. The stored draft is run through sanitize_ontology before the check and before being persisted as approved_ontology, so a draft saved before that sanitization existed doesn't get stuck reporting its own leftover instance-value-shaped attributes as conflicts forever.

A prior draft save (PUT /v1/graph/ontology/draft) may already have overridden the active ontology, through the same check, before this ever runs — approve is now more of a "lock in" step than the sole activation point.

curl -X POST "https://deepfellow-server-host/v1/graph/ontology/approve" \  -H "OpenAI-Organization: string" \  -H "OpenAI-Project: string"

{
  "id": "string",
  "project_id": "string",
  "state": "discovering",
  "ontology": {},
  "approved_ontology": {},
  "source_file_ids": [
    "string"
  ],
  "boundaries": "string",
  "last_error": "string",
  "warnings": [
    "string"
  ],
  "created_at": "2019-08-24T14:15:22Z",
  "updated_at": "2019-08-24T14:15:22Z"
}

{
  "detail": [
    {
      "loc": [
        "string"
      ],
      "msg": "string",
      "type": "string",
      "input": null,
      "ctx": {}
    }
  ]
}