add a /reflect/chat endpoint for journal reflection

[vyagh]

Brief

Server half of the Journal's reflection feature. The client side is sugarlabs/sugar#1117 onward; sugarlabs/sugar#1123 is what calls this endpoint.

What this adds

• One endpoint, POST /reflect/chat.
• The Journal sends the conversation so far; this returns the AI's next question.
• It reuses the same API-key check and quota accounting as the existing routes.

How it's put together

• I kept the conversation logic out of this repo. It lives in reflection-engine, a separate package; this service only does transport.
• The request and response bodies use the engine's own record format, passed through as-is. I didn't invent a second format for sugar-ai.
• Every request field has a size ceiling, so one quota unit cannot buy an arbitrarily large model call.
• app/reflection/bridge.py wraps our providers so the engine can call them. Our models have no JSON mode, so the bridge writes the expected schema into the prompt and strictly checks the reply.
• If the model replies with something invalid, or the provider is down, the client never sees an error. The response is still a 200, carrying a marker turn that tells the Journal to fall back to one of its own pre-written questions.

Two things I'd like settled in review

1. The dependency

The engine installs from its pinned v0.1.0 release via requirements.txt. Should it eventually live on PyPI, and under whose account?

2. Images

Requests may carry image context in the engine's encoding, size-capped here; this service never reads inside it.
Images reach the model only when the deployment sets AI_SUPPORTS_IMAGES=1 and the provider can carry image parts; otherwise they drop and the text flows on.

Tests

• 39, all against a fake provider that records the prompts it was handed: 30 on the endpoint, 9 on the bridge.
• Nothing touches a real model.

[vyagh]

@Noaman-Akhtar please take a look at your convenience