cc backend: cmake/meson stdenv units, drvPath-keyed

[r-vdp]

Stacked on #15.

Adds a second Backend for C/C++ projects built with cmake or meson via
stdenv.mkDerivation. Project-grain (one drv = one project); per-TU
incrementality comes from a persistent out-of-tree build dir at
cache.incremental_dir(drv_path) so reconfigure is warm and ninja
rebuilds only the TUs whose .d depfiles changed.

Unit declaration — drvPath sidecar, no overrideAttrs

# bob.nix
let bobCc = import "${bob}/lib/cc.nix"; in
{
  workspaceMembers = …;  # rust
  cc = bobCc.units {
    libfoo = { drv = pkgs.libfoo; src = "path/to/libfoo"; };
  };
}

bobCc.unit attaches bobCcSrc as a Nix-level attr (drv // { … }), so
drvPath is unchanged. The cc backend evaluates (import bob.nix {}).cc
once (cached on blake3(bob.nix)) to get a drvPath → src map and uses it
for is_unit and source-change tracking; nothing reaches the drv env. That
means if pkgs.libfoo also appears in some Rust crate's buildInputs,
bob build <rust-root> finds the same drv as a unit and a C edit cascades
through to the .so without any overlay plumbing or drv-hash ripple.

Supporting changes

• Backend::is_unit gains drv_path and repo_root (the cc unit set is
  declared out-of-band; the drv env alone can't tell). Threaded through
  from_roots / scheduler.
• Scheduler dispatches unit_name / build_script_hooks /
  output_populated / pipeline per-node so cc and rust units coexist in
  one graph.
• Rust backend: bob build <profile>.<crate> →
  <profile>.workspaceMembers.<crate>.build, so a repo's bob.nix can
  expose multiple cargoNix instances (e.g. prod-tuned vs dev-loop flags)
  under different prefixes.
• cli: predicate_key folds in bob.nix content so the graph cache
  invalidates when the cc-unit set changes (the root drv path doesn't move).

Limitations

• unpack/patch are skipped (the build runs against the live worktree), so
  patched derivations are not supported.
• cc edges are done-gated (pipeline() = None). The early-signal path
  (header staging + a __cc-wrap link-gate + edge-aware policy) is sketched
  in crates/cc/src/lib.rs; the per-TU incrementality here is the
  order-of-magnitude win on its own.

Tested

On a real-world ~925-unit graph with one cc unit (ndl,
aws-neuron-kmdlib) declared:

edit	bob build <rust-root>
ndl.c (cold)	3.7s configure+build+install
ndl.c (warm, 1 TU touched)	1.3s
no-op	0.02s (artifact cache hit)

The cc→rust cascade (edit ndl.c → .so reflects it) over-invalidates
without the early-cutoff work in the follow-up PR; this PR establishes the
backend and the unit model.