fix: preserve uploaded signature orientation in Firefox

[mvanhorn]

Description of Changes

Normalize an uploaded raster signature once in ImageUploader by drawing the browser-decoded image to a correctly sized canvas and emitting a PNG data URL, thereby baking the displayed orientation into the pixels and removing orientation metadata before SignSettings stores signatureData. Keep the existing SVG-to-PNG path and preserve transparency, while making the normalized raster data the originalImageData used both with background removal disabled and when that option is toggled so the raw oriented JPEG cannot re-enter the flow. Retain the existing callback contract (onImageChange receives the selected file and onProcessedImageData receives embeddable image data), so no signing-context or PDF-flattening wiring changes are required.

Uploaded image signatures can look correctly oriented while being placed in Firefox, then appear rotated by 90 degrees after the user applies them to the PDF. The reporter reproduced the problem on version 2.7.3 and again after upgrading to the latest release, narrowing it to the current upload-and-apply path rather than an already-fixed release defect. ImageUploader currently forwards non-SVG raster files as their original data URLs, allowing browser-specific handling of JPEG orientation metadata to reach the stamp preview and final PDF image pipeline in different forms. The fix is limited to image-based signatures; drawn and typed signatures should remain unchanged.

Closes #7297

Checklist

Not applicable to this change.

General

• I have read the Contribution Guidelines
• I have read the Stirling-PDF Developer Guide (if applicable)
• I have read the How to add new languages to Stirling-PDF (if applicable)
• I have performed a self-review of my own code
• My changes generate no new warnings

Documentation

• I have read the section Add New Translation Tags (for new translation tags only)

Translations (if applicable)

• I ran scripts/counter_translation.py
  Not run: no test command resolved in this workspace, so nothing was executed to pass.

UI Changes (if applicable)

• Screenshots or videos demonstrating the UI changes are attached (e.g., as comments or direct attachments in the PR)
  Not verified: this needs a person on the named hardware or environment.

Testing (if applicable)

• I have run task check to verify linters, typechecks, and tests pass
  Not run: no test command resolved in this workspace, so nothing was executed to pass.
• I have tested my changes locally. Refer to the Testing Guide for more details.
• Upload a JPEG carrying a 90-degree EXIF orientation in the Firefox-compatible image mock path; verify onProcessedImageData receives a PNG whose canvas dimensions and drawn orientation match the displayed image rather than the raw JPEG dimensions. - Upload an ordinary raster image with transparency; verify normalization keeps its width, height, and alpha-bearing PNG output and still calls onImageChange with the original File. - Toggle white-background removal after an oriented image is selected; verify processing starts from the normalized PNG and does not restore the original metadata-bearing data URL.