docs: record where ty enforcement runs and what it reads

Enforcement is decided as CI in two layers: layer 1 reads the exit status of a
bare `ty check` over the whole tree and holds error severity at zero; layer 2
reads diagnostics on the lines a change adds and reaches the rules held at
`warn`. Neither substitutes for the other, and the scoping question is what
decides whether enforcement catches anything: measured at a157c14 the tree
reports 3,287 diagnostics — 0 error, 3,287 warning — and exits 0, while the same
run with --error-on-warning exits 1. All five defects on record as caught by ty
in this repository were reported by rules held at `warn`, so none of them would
have moved the exit status of a whole-tree run.

The new `## Enforcement` section also records how a path-scoped invocation
re-establishes the checked surface (`--force-exclude`, which honours both halves
of `[tool.ty.src]`), how severity is raised per invocation without moving
`[tool.ty.rules]`, the bound the per-file overrides place on any gate's reach,
how the pinned typecheck group is installed in CI, and every placement rejected
with the measurement that rejects it.

Corrects the claims the measurement contradicts: the Makefile comment and the
policy doc's opening paragraph both said type checking was local-only and that
`make typecheck` exits non-zero, and the baseline paragraph explained the exit
codes as though any diagnostic moved the status. The recorded baseline is
re-measured to 3,287 at a157c14, and CONTRIBUTING.md now points at the
decision.

No gate is wired here; SEP-1680 ships it.

Claude-Session: https://claude.ai/code/session_01SMptAVu2dPHY9BYYUCHmnF

Author: yyyyyyyan

CONTRIBUTING.md

@@ -95,7 +95,7 @@ We enforce code style guidelines using [Ruff](https://docs.astral.sh/ruff/). The
 
 - **Type checking** (opt-in):
 
-Because the project is fully type-annotated, you can check the annotations locally with [`ty`](https://github.com/astral-sh/ty) (Astral's type checker) by running `make typecheck`. It is **not** enforced in CI or pre-commit yet, so it is safe to run on demand and will currently report a backlog of existing diagnostics. Which trees are checked and what severity each diagnostic rule carries are recorded in [docs/development/ty-policy.md](docs/development/ty-policy.md).
+Because the project is fully type-annotated, you can check the annotations locally with [`ty`](https://github.com/astral-sh/ty) (Astral's type checker) by running `make typecheck`. It is **not** enforced in CI or pre-commit yet, so it is safe to run on demand and will currently report a backlog of existing warning-severity diagnostics. Where enforcement will run and what it will read is decided and recorded in [docs/development/ty-policy.md](docs/development/ty-policy.md) under [Enforcement](docs/development/ty-policy.md#enforcement), alongside which trees are checked and what severity each diagnostic rule carries.
 
 - **Docstrings**:
 

Makefile

@@ -91,9 +91,9 @@ ruff: venv
 	@"${VENV_BIN}"/ruff check .
 	@"${VENV_BIN}"/ruff format --check .
 
-# Opt-in, local-only static type checking (Astral ty). Deliberately NOT part of `lint`,
-# pre-commit, or CI: a non-zero exit from the existing type-error backlog is expected and
-# must not gate any automated check.
+# Static type checking (Astral ty). Not yet part of `lint`, pre-commit, or CI: where
+# enforcement will run and what it will read is decided and recorded in
+# docs/development/ty-policy.md under `Enforcement`. Until then, this runs by hand only.
 typecheck: venv
 	@"${VENV_BIN}"/ty check