fix: refuse an unplaceable hunk, and resize a pool without stopping it

[thedancingdeveloper]

Two defects, both about a gate telling the truth.

A hunk with no placement is refused before the ladder runs

@@ -0,0 +... says the old file has no lines at this point. Against a file
that exists with content in it, that is false about the tree — and the second
rung acted on it anyway: git apply refuses the header, --unidiff-zero
takes the absent context at face value and inserts at line 1.

Live, that put def multiply above calc.py's module docstring, which then
stopped being a docstring at all, and put two tests above their imports.
pytest -q passed throughout, because Python does not care where a string
literal sits, so the item reached the reviewer as a success carrying damage
the harness introduced rather than the model.

apply_diff's docstring already carried the principle — fuzzy is off by
default "because a misplaced hunk that reports success is worse than a
failure". This is the same trade one rung higher, refused before anything
runs because the patch is checkable against the tree without applying it.

The rescue the ladder exists for is untouched. A header that understates
its context still names a position and --unidiff-zero still forgives it;
test_a_hand_written_hunk_header_is_rescued and its strict-apply guard pass
unchanged. What is refused is the one header that names no position at all.

It costs one honest case, measured: git diff -U0 emits exactly this header
for a line prepended to a non-empty file. Nothing in the patch tells that
apart from a model that meant "somewhere in this file", and one of the two is
damage no gate can see — so both are refused, the failure says what a usable
header looks like, and a prepend with one line of context applies as before.

The two tests from #134 that used a -0,0 diff as their fixture now use a
context-free hunk that names a real position — still rescued by
--unidiff-zero, still proposed-text ≠ applied-change, which is what they
were about.

A running pool can be resized

max_workers was persisted and then ignored: a pool kept its original thread
count until the project was stopped and started again. The obstacle was one
stop event per pool — the only answers available were "keep every worker" and
"stop the project" — so each worker now carries its own switch.

Fleet.resize computes the delta from the workers not already leaving:
growing starts only the shortfall; shrinking sets the excess workers'
switches and joins them off the caller's thread, so an in-flight item
finishes at its own boundary and nothing is killed. running() keeps
reporting threads that are alive, which after a shrink is still the old
number until those items land, and the project stays running throughout.
Concurrent resizes serialise on the fleet lock and are idempotent; a worker
the OS refuses to start is recorded as a worker failure and leaves its
siblings working. A draining or stopped pool is not resized.

Registering a project update reconciles its live pool — the surface operators
already use for max_workers — and docs/USAGE.md says so.

Verification

Every new test was run against the unfixed code first and fails there:

• with the pre-apply check removed, both -0,0 tests fail with
  applied == True, how == "git apply --unidiff-zero" — the bug, reproduced;
• with resize reduced to "return the current size" (the old behaviour), the
  four fleet tests and the API integration test fail.

Threading tests use events and predicates, no bare sleeps: a HoldingExecutor
holds an item until released, so the shrink demonstrably lands mid-item.

uv run pytest -q, ruff check ., ruff format --check . and mypy . all
pass.

Closes #133. Closes #102.