When to call: after changing code in ``repo`` and before reporting the task
as done. Call ``gate_policy`` first if you need to know the floors or
whether the baseline is pinned. Python/pytest only; changes in other
languages come back inconclusive.

What it does: writes the baseline commit's tree (every file as committed),
diffs it against the working tree (uncommitted and untracked files
included), runs the suite under coverage.py, then runs the gate: the
claims on the baseline and on the patch, the baseline's copy of any test
the patch rewrote, and mutation testing on the changed lines. Nothing is
committed or reverted.

Side effects: the repository's tests execute -- its code runs, so they may
do whatever they do when you run pytest yourself. The coverage run uses the
repository as working directory; the gate's own files go to a temporary
directory that is removed afterwards. It can take minutes. A run longer
than ``timeout_seconds`` (default 3600: the gate's own full-suite run may
take 900 alone) returns inconclusive, never a pass, and its
``next_steps`` names ``timeout_seconds`` as the limit to raise.

Arguments: ``repo`` is a path inside the git repository. ``claims`` are
pytest node ids (``path::test``) to verify; empty -> discovered from the
tests that executed a changed line. ``pytest_args`` are test paths or node
ids the coverage run collects (default: the whole suite); options such as
``-k`` are refused. ``base_ref`` is used only when the operator did not pin
ADVERSARY_GATE_BASE_REF.

Returns ``decision`` (merge / block / inconclusive), ``mergeable``,
``fix_proven``, ``reason``, per-claim results with the oracle used,
``diff_coverage``, ``suite_strength``, ``next_steps`` and the full
artefact. merge permits a human review, not a release; block means fix the
code, not the tests; inconclusive means something was not measured -- say
what. ``next_steps`` lists what would earn a MERGE (cover these lines, kill
this surviving mutant, add a new test, fix the code); do them and call
again. It never asks you to edit an existing test, a harness file or a
floor, and doing so does not help: the baseline's tests are the oracle.

When to call: before ``verify_repo``, to learn whether the baseline is
pinned by the operator or chosen by you, which interpreter runs the tests,
and which floors a merge has to clear -- or after an inconclusive or block
answer, to explain it.

Read-only and fast: it runs no tests and changes nothing. The policy comes
from the server's environment (ADVERSARY_GATE_POLICY, _BASE_REF, _PYTHON),
set by whoever configured the server; no tool can change it.

Returns ``version``, ``operator_flags``, ``defaults``, ``baseline``,
``python`` and ``agent_controls`` (the arguments of ``verify_repo`` you
decide). An invalid operator policy returns ``error`` instead.