v0.8.1

Patch release. Closes the known gap named in the v0.8.0 release body.

claude_code agents spawn with the operator's environment

agent_cc was the only one of the four spawn sites that launched without
utils.operator_env(). ADWs run under uv run, which prepends its ephemeral
dependency venv to PATH and sets VIRTUAL_ENV, so a Claude agent's Bash resolved
python3, pip, and every globally installed CLI through a throwaway build venv
instead of the operator's own toolchain. quality._run, agent_pi, and
agent_cursor have always passed it.

v0.8.0 sharpened this rather than easing it: every agent's system prompt now names
the verify gate's own argv, so a claude_code agent was actively pointed at commands
it resolved differently from the gate. Under the ensemble that put pr_reviewer_2 on
a different interpreter from reviewers 1 and 3 and from the gate itself.

The wrinkle. The Claude Agent SDK merges options.env over os.environ rather
than replacing it, and a merge cannot express a delete. Passing operator_env()
directly would correct PATH but silently restore the popped VIRTUAL_ENV, a
half-applied state no other backend produces. New utils.operator_env_overrides()
re-adds every key operator_env() dropped as an explicit blank, derived from the
diff against os.environ so it stays correct if operator_env() ever drops another
key.

Verified live, not just in tests: a real claude_code scout run reports
python3 at /opt/homebrew/bin/python3 with VIRTUAL_ENV empty, where the ADW
process itself carries ~/.cache/uv/builds-v0/.tmpXXXX. Pinned by four new tests in
engine/adws/tests/test_agent_cc.py, each of which fails if the fix is reverted.

agent_cc.py is MANAGED, so stamped repos pick this up on their next update with
no re-stamp.

Full changelog: v0.8.0...v0.8.1