Fix #20420: Prevent double decoding of file URL parameter

[Uzair-Ahmed-Shah]

Fixes #20420

Description

This PR fixes a regression where passing a URL with encoded parameters (e.g., ?token=%2Ffoo) to the viewer would fail due to incorrect double decoding.

• The Bug: In web/app.js, the file parameter retrieved from URLSearchParams was being passed to decodeURIComponent. Since URLSearchParams.get() already decodes values, this caused a second round of decoding. This corrupted URLs containing encoded characters (like %2F becoming /), which broke signed URLs or paths requiring encoding.
• The Fix: Removed the redundant decodeURIComponent call. The file parameter is now passed directly to the URL constructor, preserving the correct encoding.

Testing

Verified manually using a reproduction case:

1. Input: https://example.com/pdf?token=%2Ffoo
2. Before Fix: Resulted in ...token=/foo (Incorrect, broke the token).
3. After Fix: Results in ...token=%2Ffoo (Correct, preserves encoding).

[timvandermeij]

(re-adding the "request changes" that disappeared because the comment above is not addressed yet)

[timvandermeij]

The change looks good to me, but please squash the commits into one (see https://github.com/mozilla/pdf.js/wiki/Squashing-Commits if you're not familiar with how to do that). After that we can trigger the integration tests.