Second correctness pass on e271858 found three ways an arch-only appliance
could be written as a per-tooth job, plus a gap in the previous repair.
1. The deferred region check was never completed. A mixed-region category
resolved with no region recorded, and nothing re-validated the leaf the
clinician then picked — "پروتز متحرک برای دندون ۱۲" wrote a complete
denture onto tooth 12, which the manual chart cannot produce and which
task generation would expand as denture steps. Targets now resolve BEFORE
types, so the target kind narrows a category's candidates and an
impossible leaf is never offered. The deferral disappears with it.
2. `some` over the stack's regions let one legal code admit every other.
`types: ['pfm_crown','night_guard_soft']` on tooth 12 passed, because
`crown` suited the tooth, and wrote a night guard onto that tooth. Now
every named code must suit the target.
3. `regions.size === 1` also deferred `implant`, whose leaves span root and
crown — both tooth regions, so not a tooth/arch category at all. An
implant aimed at a jaw resolved as a UA target. Narrowing by target kind
rejects it instead.
4. The e271858 type-row lock ticked the row and the payload but not the
count, so the sheet read "Apply 1 field" while two landed. One
`effectiveSelection` now drives the count and the payload.
Also narrows a `filter(Boolean)` in the disjointness test that left two
implicit-any errors under the full tsconfig (nest build excludes specs, so
the repo gate never saw them). Pre-existing at 15ddb9a.
Adds four resolver tests: candidate narrowing per target kind, a category
with no usable leaf, a stack where only one code suits, and a legal stack.
All three defects passed the previous 209 tests.
Gates: backend 212 tests, nest build, ESLint clean on the voice module;
frontend 37 Vitest tests, tsc --noEmit, ESLint clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>