fix: support full 64-bit integer range for number inputs in uint64/ctor

[impawstarlight]

Resolves none.

Description

What is the purpose of this pull request?

This pull request:

• Lifts the restriction on number arguments to the Uint64 constructor to allow unsafe integers upto 2^64-1.

Related Issues

Does this pull request have any related issues?

No.

Questions

Any questions for reviewers of this pull request?

No.

Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.

Checklist

Please ensure the following tasks are completed before submitting this pull request.

• Read, understood, and followed the contributing guidelines.

AI Assistance

When authoring the changes proposed in this PR, did you use any kind of AI assistance?

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

If you answered "yes" to using AI assistance, please provide a short disclosure indicating how you used AI assistance. This helps reviewers determine how much scrutiny to apply when reviewing your contribution. Example disclosures: "This PR was written primarily by Claude Code." or "I consulted ChatGPT to understand the codebase, but the proposed changes were fully authored manually by myself.".

N/A.

---

@stdlib-js/reviewers

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
number/uint64/ctor	$\\color{red}581/641$ $\\color{green}+0.00\\%$	$\\color{red}48/51$ $\\color{green}+0.00\\%$	$\\color{red}9/11$ $\\color{green}+0.00\\%$	$\\color{red}581/641$ $\\color{green}+0.00\\%$

The above coverage report was generated for the changes in this PR.

[kgryte]

Not clear why this change is necessary, but I'll defer to your judgment.

[impawstarlight]

Because calling toString on an unsafe integer truncates the trailing digits to zero even though those digits are exactly representable in double, which we can see with toPrecision. But there's no way to use toPrecision with arbitrary radix, so we need rely on BigInt for precise serialization with specified radix in this test.

[kgryte]

Thanks for the explanation.

[kgryte]

I feel like #.toString behavior is odd here and a likely source of confusion, especially when used in the REPL. Maybe we should add a dedicated utility to number/float64/to-exact-string (name?) to provide something more robust.

[kgryte]

After a bit of back-and-forth with ChatGPT, I understand why #.toString behaves as it does (namely, serialize to the shortest representation which generates the exact same double). But, for usage in the REPL, this can lead to misleading results.