Reject order ids that are not all digits

[sergical]

nextOrderId now throws a RangeError when the last id has anything other than digits, so a stray space or a letter no longer turns into NaN. It also reads the id with Number instead of parseInt.

Created with Claude Code

[github-actions]

Verdict: Approve with minor follow-ups — the stricter validation is a good improvement, but a few edge cases and style nits deserve attention.

Correctness

• Behavioral/breaking change: Previously nextOrderId silently returned "NaN" for non-numeric input (via parseInt); now it throws RangeError. This is arguably an improvement, but it is a breaking change — any existing callers relying on the permissive behavior (or passing legacy/malformed IDs) will now crash instead of degrading. Worth confirming call sites handle/expect this.
• Whitespace regression: parseInt(" 123") previously tolerated leading/trailing whitespace and returned 123; the new ^\d+$ regex rejects it outright, throwing on inputs that used to work. If any upstream source can produce whitespace-padded IDs, this is a regression worth testing for.
• Leading zeros: "007" still passes the regex but Number("007") + 1 → "8", dropping zero-padding — same latent issue as before, not introduced by this diff, but the new “strict” validation may give false confidence that formatting is fully handled.
• Large IDs / precision loss: Number(last) loses precision beyond Number.MAX_SAFE_INTEGER, so very large order IDs could silently increment incorrectly. Pre-existing issue (not a regression), but the PR doesn't address it despite tightening validation elsewhere — consider BigInt if IDs can grow large.
• Empty string: now throws instead of previously returning "NaN". New failure mode, likely an improvement, but should be covered by a test.

No automated tests exist for this file (run_tests reported no related tests), so none of the above edge cases are currently verified.

Style

• No explanatory comment for why non-numeric IDs are now rejected or what format is expected (leading zeros? whitespace?).
• RangeError is a slightly odd choice semantically — this is a format/validation failure, not an out-of-range value. A dedicated error type (e.g., InvalidOrderIdError) or TypeError would communicate intent more clearly.
• Minor message casing: "Order id" vs. "Order ID" — pick a consistent convention.
• Parameter name last is a little terse; lastOrderId would read more clearly alongside nextOrderId.

Suggested follow-ups

Add unit tests covering: non-numeric input (throws), empty string, whitespace-padded input, leading zeros, and a large numeric string near/above MAX_SAFE_INTEGER.