FIX: apply font_color to PDFs PDFConverter generates

[Utkarsh Bahuguna (u7k4rs6)]

Fixes #3105.

Went with the option that doesn't change anything for people who don't pass a color:

• font_color now defaults to None.
• Generated PDFs set the fill color to font_color, or black when it isn't set (same as today), and set it again after each page break.
• Injection items without their own color still fall back to white when font_color isn't set, so hidden injected text keeps working. If font_color is set, they use it.
• font_color is in the identifier when set. Unset is dropped, so default PDFConverter hashes don't move. I left row_height/column_width/injection_items out to keep this small.

Tests go through convert_async and read the fill-color ops back out of the PDF content stream:

• generated PDF over several pages with no color, red and white
• injection with every combo of converter color and item color
• identifier with and without a color
• invalid colors still raise

The new ones fail on main. tests/unit/converter, registry and backend/test_converter_service: 2928 passed.

[Roman Lutz (romanlutz)]

🟡 Should Fix: This new helper fails the project's type check. uv run --no-sync ty check pyrit\converter\pdf_converter.py tests\unit\converter\test_pdf_converter.py reports invalid-return-type: tuple(...) has type tuple[int, ...], but the return annotation requires exactly three channels (tuple[int, int, int]).

Please unpack each match and build an explicit three-element tuple:

(
    round(float(red) * 255),
    round(float(green) * 255),
    round(float(blue) * 255),
)
for red, green, blue in _FILL_COLOR_OP.findall(...)

That preserves the RGB contract and removes this error. The documented make ty target includes unit tests, so passing pytest alone does not catch it.

[Utkarsh Bahuguna (u7k4rs6)]

Done in 1dc9c00, now it unpacks the three channels so the helper returns a real tuple[int, int, int]. ty is clean on both files, and I've started running it on the test files too.