fix(agent): keep incremental builds when CI is set - #15

Cargo 1.99 (cargo#17220) turns incremental compilation off whenever CI
or TF_BUILD is set. It applies that switch after merging profiles, so it
beats [profile.*] incremental = true, and a unit's hash includes the
result. An agent tool that exports CI therefore made an agent rebuild
every workspace member of a base warmed without it, and its first edit
compiled without incremental state, which is most of what Ferry gains on
Linux. A base warmed with CI set had the same problem the other way.

Only CARGO_INCREMENTAL and build.incremental rank above the switch, so
the cargo Ferry runs for an agent (ferry run, the shim, hooks) and for a
base's warm commands now gets CARGO_INCREMENTAL=1 when all hold: the
toolchain is Cargo 1.99 or newer (the base's recorded one for agents,
the one it detected for warming), CI or TF_BUILD is set, and neither
CARGO_INCREMENTAL, CARGO_BUILD_INCREMENTAL nor build.incremental in a
--config value or a .cargo/config{,.toml} the call reads is. CI and
TF_BUILD stay as they are for everything cargo runs. Cargo's arguments
are left alone, so aliases keep working, and an external subcommand
such as cargo nextest hands the variable on to the cargo it runs.

The costs, documented: under CI, release and bench builds become
incremental too, and [profile.*] incremental = false is overridden.
CARGO_INCREMENTAL=0 opts out.

Closes #2.

A base warmed with CI set builds its release units incrementally, under
Ferry's CARGO_INCREMENTAL=1, and one warmed without it does not. A
refresh with CI set, seeded from a base warmed without it, therefore
used to keep the seed's release units as if both selected the same
units, and a plain agent's cargo run --release found them fresh with the
seed's code. Counting CI among the unit inputs fixed that; this test
keeps it fixed, and checks that dev units still match across the
difference.

Each nested workspace builds into a target dir of its own, under
ferry-ws, and is a case of its own (Workspace::Nested) where the shim
and ferry run decide to set CARGO_INCREMENTAL=1. Nothing checked that it
gets the variable under CI: if the warm commands or an agent left it
out, the nested units would differ and every agent build of the nested
workspace would rebuild it. The test warms a base with CI set and builds
the nested workspace in an agent with and without CI; neither may
rebuild anything.

A build.incremental in $CARGO_HOME/config.toml ranks above Cargo's CI
switch, so Ferry must leave CARGO_INCREMENTAL unset then, but no test
covered Cargo home: cargo_configs read it from the process environment,
which a unit test cannot set safely. cargo_configs now takes Cargo home
as an argument, keep_incremental passes the real one, and a unit test
passes one with build.incremental set.

The CI notes left out three consequences readers can trip over. Release
and bench units of a base and an agent match only when both have CI or
TF_BUILD set or both lack it, since only CI makes them incremental. A
refresh across a change in CARGO_INCREMENTAL or in whether CI or TF_BUILD
is set is now seeded across unit inputs, so it is pruned, or built from
scratch when its warm build is not observed. And processes cargo starts
inherit Ferry's CARGO_INCREMENTAL=1, so a cargo call a build script or
test makes on a workspace outside the agent builds incrementally too.
The lists of what makes a refresh prune now name the incremental
settings as well.

A base warmed by an older Ferry with CARGO_INCREMENTAL or CI set has the
unit inputs the new code computes when they are unset. A refresh warmed
without them was then seeded as same-input, kept the old base's units
unpruned, and an agent selecting them under mtime freshness ran the old
code. Salting the hash with a version makes every base recorded under
the old definition a cross-input seed once: pruned if its warm build was
observed, rebuilt from scratch otherwise.

unit_inputs also takes the CI variables from shim::CI_VARS now.

An explicit [profile.*] incremental = false is overridden under CI, so
agents with CI set rebuild that profile's crates of a base warmed
without it; build.incremental = false keeps both. Whether CI is set is
a unit input on every Cargo version. includes, cargo -C and a nested
workspace's own toolchain file are not followed.