Instrument and improve incremental workspace checks

Profile source capture, Nix evaluation/realization, resource/query checking,
and implementation builds without putting timings into immutable outputs.
Keep modular repositories; bound independent capture work, snapshot jj once
per observation, and retain final concurrent-edit and Git completeness checks.

Compose exact resource/closure/frontend/toolchain checks as memoized Nix
derivations. Preserve whole-workspace validation and the full compiler path
when no checked dependency is supplied. Share canonical Nixpkgs by content,
index workspace build contexts once, and narrow lock/driver/compiler inputs
with conservative complete-source fallback. Batch React witness checks only
when distinct source closures cannot share ambient declarations; otherwise
run the original independent TypeScript checks.

Seed local authoring toolchains with exact canonical fetch identities when
they match the selected inputs; retain store-path inputs for overrides.
Add generic correctness checks rather than permanent Reader timing/content
fixtures. Verify actual Reader edits and rejection/recovery in a private
workbench, preserving the original user's workbench and runtime.

Query checking currently caches at resource/closure boundaries, not individual
query semantic dependency boundaries. Template helper pins and reproducible
fixture snapshots follow in a separate publication change.

PORTABLE_ARTIFACTS.md

@@ -31,6 +31,16 @@ excluded from the implementation source tree. The `plan` argument on the low-lev
 helper is a composition convenience for fixtures; it is projected before building.
 Package recipes receive the contract directly and can be checked without a workspace.
 
+Inside `checkedArtifacts = context: ...`, the package helpers expose
+`camino.packageSet { inherit nixpkgs system context; }` as the usual package set
+selection. It shares the workspace composition's evaluated Nixpkgs when the
+source content, system, and default import arguments match. Pass ordinary Nixpkgs
+arguments such as `config` or `overlays` to use a separate import. A direct
+`import nixpkgs { inherit system; }` also works, with additional evaluation cost.
+The implementation groups depend on the complete execution compiler bundle and
+JavaScript build drivers by content; unrelated checker CLI and publication
+metadata changes do not enter those inputs.
+
 The handler entry exports `registry = createRegistry(handlers)` from the generated
 bindings. One registry contains many exports. The builder always supplies a server
 implementation for the generated process service. A service-only package instead