Authenticode-sign release binaries

Is your feature request related to a problem? Please describe.
Neither the managed QuestPDF.dll nor the native binaries in the published NuGet packages carry an Authenticode signature. Any consumer who needs signed binaries has to intercept and re-sign QuestPDF's own build output themselves as an extra step in their own pipeline, rather than being able to trust it as shipped. This also isn't purely a build-time inconvenience anymore: Windows 11's Smart App Control blocks unsigned binaries from running by default (on by default for clean installs), so an unsigned native DLL loaded at runtime by a consuming app can get silently blocked on an ordinary end user's machine.

Describe the solution you'd like
Have the release pipeline Authenticode-sign the published outputs — with an RFC 3161 timestamp, so the signature stays valid after the certificate expires — for:

the managed QuestPDF.dll
the native binaries for every windows platform you publish (win-x64, win-x86)

Describe alternatives you've considered
Re-signing the output ourselves as a post-build step in our own CI. It works, but it's a manual step every consumer who cares about signing has to independently discover, implement, and keep running on every release — rather than something QuestPDF ships already solved. And it's not covered by your license, so not sure if this even is allowed?

Inspect the release pipeline and published NuGet package outputs first; the issue identifies QuestPDF.dll and the win-x64 and win-x86 native binaries as the signing targets. Determine how certificate handling and RFC 3161 timestamping fit the release process, then verify that all listed Windows binaries carry valid Authenticode signatures.