fix: encode native signature stamps as WinAnsi

[w3lld1]

Fixes #8155

Summary

• I convert UTF-8 signature stamp text to Windows-1252 before writing PDF literal strings and declare /WinAnsiEncoding for Helvetica.
• I use multibyte-aware length and substring operations so wrapping and centering do not split UTF-8 characters.
• I reject characters outside WinAnsi explicitly instead of writing corrupted bytes into a signed document.
• I added focused regression tests for accented text, multibyte wrapping, and unsupported characters.

How to test

1. Configure the PhpNative signature engine.
2. Set a signature text template containing accented characters, for example Signé par Renée.
3. Sign a document and confirm the visible stamp preserves the accents.
4. Try a character outside WinAnsi and confirm signing fails explicitly rather than producing mojibake.

Validation

• Focused SignatureStampAppearanceBuilderTest: 3 tests, 6 assertions passed on PHP 8.4.24.
• PHP CS Fixer dry run passed for both changed files.
• PHP syntax checks and git diff --check passed.
• The full Nextcloud-backed PHPUnit matrix was deferred to CI because this local checkout does not include a Nextcloud server bootstrap.

API / back-end changes

• Native PDF stamp text now uses WinAnsi bytes with a matching font encoding.
• Unit tests cover the changed behavior.
• No API or OpenAPI changes.

Checklist

• I have read and followed the contribution guide.
• The commit uses Conventional Commits and includes a DCO sign-off.

[vitormattos]

I think we should fix this first in LibreSign/xobject-template.

This package is responsible for building the XObject content and resources, so Unicode font support should be handled there instead of adding a WinAnsi limitation in LibreSign.

We also need to check if signer-php needs any change to support the font resources generated by xobject-template.

After this is ready, we can release a new version of xobject-template, add it to LibreSign, and use it from SignatureStampAppearanceBuilder.

Then we can update this PR if it is still needed, or close it if the new integration replaces these changes.

[vitormattos]

I opened the follow issue to handle Unicode support in the XObject renderer:

• Support Unicode text in PDF XObject output xobject-template#33

I think this should be fixed there first. After that change is merged and released, we can update this PR to use the new support, or close it if these changes are no longer needed.