fs: validate position argument before length === 0 early return

[geeksilva97]

Move position validation upwards to match documented behavior.

Fixes #62638

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.80%. Comparing base (68d7b6f) to head (de1c243).
⚠️ Report is 517 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #62674      +/-   ##
==========================================
+ Coverage   89.77%   89.80%   +0.03%     
==========================================
  Files         673      699      +26     
  Lines      203820   216235   +12415     
  Branches    39175    41331    +2156     
==========================================
+ Hits       182987   194199   +11212     
- Misses      13152    14148     +996     
- Partials     7681     7888     +207     

Files with missing lines	Coverage Δ
lib/fs.js	98.19% <100.00%> (+<0.01%)	⬆️
lib/internal/fs/promises.js	92.94% <100.00%> (-5.79%)	⬇️

... and 321 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.

[afurm]

Moving validatePosition before the length === 0 early return is a good catch — it means invalid positions are rejected even for zero-length reads, which is more consistent.

One question on the validation ordering: Previously, validateOffsetLengthRead ran before the position normalization, and validatePosition ran after. The relative ordering of validateOffsetLengthRead vs validatePosition changed — do these validations have any ordering dependencies or could they produce different error messages depending on which runs first? For example, if position is valid but offset + length is out of bounds, which error should the user see first?

On the new test cases: The tests with empty buffer and an invalid position object are good — but note that validatePosition will throw ERR_INVALID_ARG_TYPE for non-number objects. The existing tests in the same file use ERR_INVALID_ARG_TYPE for invalid positions, so this is consistent — just making sure that is the intended behavior.