doc: name both flags a worker's execArgv needs

--vfs-load requires --experimental-vfs, so a worker that is handed its own
execArgv needs both of them to load a script from the mount, not only
--vfs-load. Passing --vfs-load alone happens to mount the source today,
because the requirement is checked once for the process rather than for
each thread's execArgv, but it leaves node:vfs unavailable to the
worker's own code, and it is not what the option documents.

Name both options in the worker paragraph, and say that
--experimental-vfs is also what makes node:vfs available there.

Signed-off-by: Philipp Dunkel <pip@pipobscure.com>

Author: pipobscure

doc/api/cli.md

@@ -3827,11 +3827,12 @@ mounts it, whatever else that thread mounts, so a path into the mount means the
 same thing in all of them.
 
 A worker created with its own `execArgv` inherits none of the parent's options,
-and so does not mount the source at all. Such a worker must be given the same
-`--vfs-load` to run a script from the mount; without it, that thread has no
-mount for the script to come from, and the worker fails to load it. A worker
-whose script comes from anywhere else, such as the real file system, needs
-nothing added.
+and so does not mount the source at all. To run a script from the mount, such a
+worker must be given the same options again, `--experimental-vfs` and
+`--vfs-load`; without them, that thread has no mount for the script to come
+from, and the worker fails to load it. `--experimental-vfs` is also what makes
+[`node:vfs`][] available to the worker's own code. A worker whose script comes
+from anywhere else, such as the real file system, needs nothing added.
 
 `--vfs-load` is not permitted in [`NODE_OPTIONS`][]: which entry point runs is
 the command line's decision, and the environment must not be able to redirect

doc/node.1

@@ -1917,11 +1917,12 @@ The source is mounted at the same reserved mount point in every thread that
 mounts it, whatever else that thread mounts, so a path into the mount means the
 same thing in all of them.
 A worker created with its own \fBexecArgv\fR inherits none of the parent's options,
-and so does not mount the source at all. Such a worker must be given the same
-\fB--vfs-load\fR to run a script from the mount; without it, that thread has no
-mount for the script to come from, and the worker fails to load it. A worker
-whose script comes from anywhere else, such as the real file system, needs
-nothing added.
+and so does not mount the source at all. To run a script from the mount, such a
+worker must be given the same options again, \fB--experimental-vfs\fR and
+\fB--vfs-load\fR; without them, that thread has no mount for the script to come
+from, and the worker fails to load it. \fB--experimental-vfs\fR is also what makes
+\fBnode:vfs\fR available to the worker's own code. A worker whose script comes
+from anywhere else, such as the real file system, needs nothing added.
 \fB--vfs-load\fR is not permitted in \fBNODE_OPTIONS\fR: which entry point runs is
 the command line's decision, and the environment must not be able to redirect
 it.