fix(pdf): accept owner-password PDFs that open with an empty user password (Fixes #3303) - #3350

Fixes #3303.

What changed

normalizePdf no longer rejects every PDF that carries an encryption dictionary. It now separates the two cases the old blanket isEncrypted check lumped together:

1. Document opened with an empty user password (owner-password protection, the common government-form case). The pages get rebuilt into a fresh document via extractPages, which drops the encryption dictionary without needing owner access, and normalization continues. This is the approach verified in the issue; PDF.merge and removeProtection() were ruled out there already.
2. Document did not authenticate (a real user password). Rejected with a message that says the file is password protected, instead of the generic "The document is encrypted" both cases used to share (Show error message about encrypted PDFs #1371 asked for exactly this).

The rebuild does not carry the AcroForm over, so case 1 is gated on shouldFlattenForm. Today flattenForm: false is only the TEMPLATE path (create-envelope-items), so every signing path gets the fix and templates keep refusing rather than silently losing fields. If #2853 lands and a path stops flattening, that gate should follow it.

Also switched pdfDoc from const to let for the reassignment.

Verification

I reproduced the whole thing locally against @libpdf/core 0.4.2 (the version pinned in package.json) with qpdf-built fixtures:

• Owner-password PDF (AES-256, empty user password, permissions-only): loads, isEncrypted=true, isAuthenticated=true, rebuild produces a file that reloads with isEncrypted=false, page content intact.
• Unencrypted PDF: identical output to before, no behavior change.
• Same owner-password PDF with flattenForm: false: throws the new "would discard its form fields" message.
• User-password PDF: on 0.4.2 PDF.load itself throws before my branch is reached, so it keeps the existing "not a valid PDF" error. The isAuthenticated backstop is there for paths and versions where load succeeds unauthenticated, which the issue observed on 0.4.0.

One follow-up worth tracking, noticed while testing: for a genuinely locked file, libpdf 0.4.2 surfaces a misleading parse error ("Root Pages object is not a dictionary") rather than anything password-related, so the load-failure catch cannot reliably tell corruption from a password prompt. That is a @libpdf/core issue more than a Documenso one.