src: fix crash in GetErrorSource() for invalid using syntax

[semimikoh]

Fixes: #62767

V8 can report an invalid source range for some malformed using and
await using declarations, with the end column preceding the start
column. GetErrorSource() currently asserts that the end column is
greater than or equal to the start column before reaching the existing
bounds check, so formatting the SyntaxError aborts the process.

Remove the assertion and only apply the script start offset when both
columns can be adjusted. Invalid ranges now fall through to the existing
fallback path, which prints the error source without an underline instead
of crashing.

Add regression coverage for the four invalid using / await using
cases reported from test262.

Refs: https://github.com/tc39/test262

Verification

$ ./tools/test.py -J --mode=release test/parallel/test-cli-eval-invalid-using.js

All tests passed.

$ out/Release/node tools/eslint/node_modules/eslint/bin/eslint.js --cache test/parallel/test-cli-eval-invalid-using.js

No lint errors.

$ tools/cpplint.py src/node_errors.cc

Done processing src/node_errors.cc

$ git diff --check -- src/node_errors.cc test/parallel/test-cli-eval-invalid-using.js

No whitespace errors.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.66%. Comparing base (d080801) to head (50e788d).
⚠️ Report is 31 commits behind head on main.

Files with missing lines	Patch %	Lines
src/node_errors.cc	0.00%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62770      +/-   ##
==========================================
- Coverage   91.55%   89.66%   -1.89%     
==========================================
  Files         355      706     +351     
  Lines      149381   218268   +68887     
  Branches    23364    41778   +18414     
==========================================
+ Hits       136765   195716   +58951     
- Misses      12354    14460    +2106     
- Partials      262     8092    +7830     

Files with missing lines	Coverage Δ
src/node_errors.cc	63.76% <0.00%> (ø)

... and 475 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[aduh95]

Suggested change

	'async function f() { { await using x=null, []=null; } }',
	'async function f() { { await using x=null, {}=null; } }',
	'async function f() { await using x=null, []=null; }',
	'async function f() { await using x=null, {}=null; }',

or even

Suggested change

	'async function f() { { await using x=null, []=null; } }',
	'async function f() { { await using x=null, {}=null; } }',
	'{ await using x=null, []=null; }',
	'{ await using x=null, {}=null; }',

[Renegade334]

V8 doesn't guarantee that these will behave in an ordered way, so this looks like a worthwhile change.

However, the test case is probably a genuine V8 parser bug (the message's end_position ends up being one less than its start_position, hence the previous assertion failure), so I'm not sure that it's worthwhile hard-coding this as a Node.js test; the quirky behaviour it relies upon is liable to be patched upstream.

[legendecas]

However, the test case is probably a genuine V8 parser bug (the message's end_position ends up being one less than its start_position, hence the previous assertion failure), so I'm not sure that it's worthwhile hard-coding this as a Node.js test; the quirky behaviour it relies upon is liable to be patched upstream.

Agreed. This test case could be a clunky failure when V8 is upgraded. We can remove the test.

[semimikoh]

Thanks for the reviews!
@aduh95 @Renegade334 @legendecas Removed the test cas