src: fix cpSyncCopyDir to dereference symlinks when dereference option is set

[crawfordxx]

Summary

When fs.cpSync() or fs.promises.cp() is called with {dereference: true},
symlinks in the source directory should be followed and their targets copied
to the destination as real files/directories. This behavior was correctly
implemented in the original JavaScript version of cpSync, but was lost when
the inner directory-copy loop was migrated to C++ in PR #58461.

Root Cause

In CpSyncCopyDir (src/node_file.cc), the dereference parameter was
captured by the lambda but only used for error-condition checks:

if (!dereference && is_directory(symlink_target) && ...) { /* error */ }
if (!dereference || (!force && error_on_exist)) { /* error */ }

At the end of the is_symlink() branch, a new symlink was always created
at the destination regardless of whether dereference was true:

if (dir_entry.is_directory()) {
  create_directory_symlink(symlink_target_absolute, dest_file_path, error);
} else {
  create_symlink(symlink_target_absolute, dest_file_path, error);
}

Fix

When dereference is true and we encounter a symlink:

• If the symlink target is a directory: create the directory and recurse via copy_dir_contents()
• If the symlink target is a file: copy the file content via copy_file()

When dereference is false (the default), behavior is unchanged — a new
symlink is created at the destination.

Test

Existing test case in test/parallel/test-fs-cp.mjs covers the dereference
option. The specific scenario from #59168 (symlink to a file outside the source
directory with {dereference: true, recursive: true}) now produces a regular
file at the destination instead of a symlink.

Fixes: #59168

[themavik]

The dereference branch in CpSyncCopyDir now copies symlink targets via copy_dir_contents / copy_file instead of recreating links — correct behavior. nit: confirm filters (should_copy_signal / dirent_filter) still apply the same when the walk hits dereferenced symlinks as for ordinary entries.