fs: normalize dot segments in rm and rmSync

[RohithPariki]

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

fs

Description of change

When paths containing relative dot segments (such as . or ..) are passed to fs.rm(), fs.rmSync(), or fs.promises.rm(), the different underlying implementations (binding.rmSync via std::filesystem::remove_all vs JavaScript rimraf) produce divergent results:

• In rimraf, child paths are constructed by concatenating onto the unresolved path. When recursion removes intermediate directory components, subsequent calls fail with ENOENT, which rimraf treats as "already deleted," causing silent partial removals.
• rmSync throws an error without a .code property on paths with trailing /..

This PR normalizes dot segments before reaching the underlying removal routines:

• Introduces normalizePathForRm() in lib/fs.js and lib/internal/fs/promises.js.
• Correctly handles both string and Buffer inputs: for Buffer paths, binary byte content is preserved 1:1 using latin1 round-tripping before and after normalization to prevent data corruption on non-UTF-8 paths.
• WHATWG URL inputs are converted to strings via getValidatedPath() before normalization.

Tests

Added regression tests in test/parallel/test-fs-rm.js covering:

• The full relative path matrix (a/b/../., a/b/.., a/., a/b/c/., a/b/c/../.., a/b/c/d/../../.., a/b/.././b, ./a) across fs.rmSync, fs.rm (callback), and fs.promises.rm.
• Buffer paths across sync and promises implementations.
• Non-UTF-8 binary Buffer paths to ensure byte preservation.

Fixes: #61958

[github-actions]

Welcome to Node.js, and thank you for your first contribution!

Before review, please take a moment to read:

• the guide for first-time contributors
• the contribution and automation policies
• the pull request guide
• the AI use policy
• the Code of Conduct

Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal.

[MikeMcC399]

You have an open unapproved PR #66471 and so you have already reached the limit of 1 open unapproved PR for a "first-time contributor".

The recommendations in:

• Guides and FAQs for first-time contributors

advise you should tackle only one issue at a time and that you should not open any new PRs until your first PR has been approved.

You already acknowledged this rule in #66472 (comment)