fix PDF to Image conversion mis-rendered (PDFBOX-6232)

[valerybokov]

Root cause: PageDrawer.TransparencyGroup.getOrigin() decides how to position a luminosity soft mask using a single flipTG flag — flip-branch for masks applied directly, no-flip-branch for masks used inside a tiling pattern (the PDFBOX-5966 fix). That's wrong when the tiling pattern itself is used inside an enclosing transparency group (e.g. an isolated group): the enclosing group temporarily overwrites pageSize/xform to describe its own (already y-flipped) buffer, so the no-flip branch samples the mask at the wrong offset — the pattern's gradient collapses toward the backdrop color, producing the reported "hard-seamed horizontal bands."

Fix: use the flip branch whenever nested inside an enclosing transparency group (!transparencyGroupStack.isEmpty()), in addition to the existing !flipTG condition — one line plus an explanatory comment in PageDrawer.java.

See test: #520

Per https://www.apache.org/legal/generative-tooling.html: portions of this PR were
produced with assistance from Claude Code (Anthropic), based on a bug was described in Apache PDFBOX Issue Tracker.

I've reviewed the generated code and confirm to the best of my knowledge that the output does not include any
third-party copyrighted material and is compatible with the Apache License 2.0.

[THausherr]

Thank you, I have asked the reporter to test this on his own files. I tested on mines and there are no regressions, but also no improvements on other files. However a reduced file (that I've just attached) that wasn't in my test set now comes up blank. But that file was already wrong before (flipped). That reduced file had so much reduced that it might be a different problem, I remember that I got carried away and had deleted the intermediate files.