bug: the quality score and the OCR aggregate disagree on the confidence floor

Deployment

Other

Version

Branches fix/1669-quality-score-ocr-confidence and fix/1677-ocr-aggregate-page-route, both open.

Description

Two changes now compute the same quantity from the same source, and they disagree about when it is trustworthy.

The quality score fix reads per-page OCR confidence directly and requires at least 20 recognised words before it will use the value. It reads it directly because the aggregate field was empty at the time.

The aggregate fix now populates that field, using the same word-count weighted mean, and requires only more than zero words.

Once both are merged the computation exists twice, and the floors differ. A document with fewer than 20 recognised words reports a real aggregate confidence while its quality score stays uncapped, so the two numbers describe the same OCR run and disagree about whether it was good.

Nothing is double counted; they feed separate output fields.

Steps to reproduce

1. Merge both branches.
2. Extract a scanned document short enough to yield fewer than 20 recognised words.
3. Compare the aggregate confidence against the quality score.

Logs and configuration

Either resolve it by having the quality score consume the now-populated aggregate instead of recomputing it, or by aligning the two floors and stating why two computations remain.

This could not be fixed from either branch alone without editing the other, which is why it is filed rather than folded into one of them.