Two doc sites still claimed the default was `true` after the
behaviour flipped:

- `Config::enable_global_virtual_store` field doc (lib.rs:208-213):
  the trailing "Default `true`, mirroring upstream's L392-L394" was
  the same misreading the function itself had. Replaced with the
  correct framing — `false`, with the link kept but reframed as
  "applies only inside upstream's `--global` branch".
- `WorkspaceSettings::enable_global_virtual_store` (workspace_yaml.rs):
  same fix, same reasoning.
- `gvs_default_is_off_and_paths_derive_cleanly` test doc (lib.rs):
  the opening sentence still said `enableGlobalVirtualStore` defaults
  to `true`. Restructured so the "default false" line leads and the
  derivation-still-fires note follows.

CI auto-detect bullet dropped from the field doc — it was always a
follow-up bullet (pacquet#432) and reads as noise next to the
corrected default. The original tracking still exists on the
issue.

The [`default_enable_global_virtual_store`] intra-doc link in
`Config::enable_global_virtual_store`'s doc resolved locally with
`--document-private-items` but tripped
`rustdoc::private-intra-doc-links` (a pub item linking to a private-
module symbol) on CI's `RUSTDOCFLAGS="-D warnings"` build.

Two sites:
- Field doc: replaced the intra-doc link with a plain backticks
  reference + a "see `crates/config/src/defaults.rs` for the full
  reasoning" pointer.
- Test doc: changed the link target to the public field
  `Config::enable_global_virtual_store`, which lives in the same
  module and is fine.

Copilot caught a regression introduced by flipping the
`enableGlobalVirtualStore` default to `false`. The `node --version`
detection in `InstallFrozenLockfile::run` was hoisted *before*
`CreateVirtualStore::run` in #444 because the GVS-aware layout
needed `engine_name` upfront. With GVS now off by default, that
hoist costs ~tens of ms of synchronous spawn on the install
critical path — the value just gets passed into a
`VirtualStoreLayout::new` that immediately returns without using it.

`engine_name` is still used by `BuildModules` for the side-effects-
cache key prefix (cache defaults to on), so dropping the spawn
entirely isn't right. Instead, split the detection by GVS state:

- **GVS on**: spawn synchronously, same as today — layout needs it.
- **GVS off, no host yet**: spawn into `tokio::task::spawn_blocking`
  and keep the `JoinHandle`. The blocking pool runs the spawn
  concurrently with `CreateVirtualStore::run`'s I/O. Await right
  before `BuildModules`, so the `node` startup cost is hidden
  under the install rather than serialised before it.

`VirtualStoreLayout::new` is built with `None` on the deferred
path, which is fine because GVS is off and the layout ignores the
field in that path. Pre-GVS pacquet had this same overlap; this
restores it for the default config.