fix(lib-node): version-key extraction path to bust ESM module cache

[albanm]

Rework lib-node's ensureArtefact to extract each artefact into a content-versioned directory behind a stable per-buildTuple pointer file, so a changed artefact resolves to a brand-new path and Node's ESM module registry reloads the entire graph (entry + siblings + bundled deps), not just the query-busted entry.

Why: plugins were not refreshed in memory after a registry update in long-lived processes. ensureArtefact re-extracted to a stable path, so the ESM registry (keyed by resolved URL) kept serving the stale module graph; the existing ?imported=Date.now() only re-evaluated the entry module.

New cache layout:

<artefactId>/
  .pointer-<buildTuple>.json        # stable: { dataUpdatedAt, version, dir }
  <version>+<epochSeconds>/<buildTuple>/

The stable pointer drives the conditional GET. On 304 we return its existing dir; on 200 we extract to a new dir, atomically repoint, then prune dirs no pointer references. The path discriminator is dataUpdatedAt at epoch-second precision, matching the registry's If-Modified-Since criterion exactly — the same equivalence relation gates both the 304/200 decision and the cache-bust. Keying on dataUpdatedAt (not version) also covers same-version re-publishes and an empty x-artefact-version header. Released as @data-fair/lib-node-registry 0.7.0.

Regression risks:

• One-time effect on upgrade: existing caches use the old <buildTuple>/.meta.json layout, so the first call per artefact reads as cold (one re-download) and the old bare <buildTuple> dir is pruned. Intended, not a silent no-op.
• The returned path is no longer stable across versions (by design). Any consumer that persisted the path across an update must re-call ensureArtefact; the processings API already re-calls on every prepare.
• Pruning is lazy/best-effort: a concurrent in-flight run reading a dir being pruned is tolerated (errors swallowed). Fine on Linux; could surface as EBUSY on Windows.
• hasNativeModules is no longer stored in the cache metadata — safe, it was only ever read from the response header on the 200 path.