Short title (summary): Fix compiler error on loong64 by correcting narrowing conversion

Description

• What did you change and why? (1-3 sentences)
• Issue reproduced / related issue: link the issue if relevant (e.g. Fix typo in title #123)

Fixed a narrowing conversion that caused build failures on the loong64 architecture. The to_bitmask() function
returns an int, which was being assigned to a uint64_t variable, causing a compiler error with the
-Werror=narrowing flag. This was resolved by adding an explicit static_cast<uint64_t> to the return value.

Type of change

• Bug fix
• New feature
• Refactor / cleanup
• Documentation / tests
• Other (please describe):

How to verify / test

• Add additional tests to verify bugs or new features.
• If you claim performance gains, you should provide benchmark numbers using high quality benchmarking code.

This change can be verified by building on Arch Linux for Loong64 where the build was
previously failing due to the narrowing conversion error. A successful build confirms the fix.
All the tests pass now.

Here is the log:

• Build: simdjson-1:4.0.3-1-loong64-build.log
• Test: simdjson-1:4.0.3-1-loong64-check.log

Please read before contributing:

• CONTRIBUTING: https://github.com/simdjson/simdjson/blob/master/CONTRIBUTING.md
• HACKING: https://github.com/simdjson/simdjson/blob/master/HACKING.md

If you can, we recommend running our tests with the sanitizers turned on.
For non-Visual Studio users, it is as easy as doing:

cmake -B build -D SIMDJSON_SANITIZE=ON -D SIMDJSON_DEVELOPER_MODE=ON
cmake --build build
ctest --test-dir build

Our CI checks, among other things, for trailing whitespace. If a test fails for that reason,
use the "artifacts" button to download the artifact and inspect the problematic lines,
or run scripts/remove_trailing_whitespace.sh locally if you have a bash shell and sed.

Checklist before submitting

• I added/updated tests covering my change (if applicable)
• Code builds locally and passes my check
• Documentation / README updated if needed
• Commits are atomic and messages are clear
• I linked the related issue (if applicable)

Final notes

• For large PRs, prefer smaller incremental PRs or request staged review.

Thanks for the contribution!