Generator: an invalid curated method name also reports a misleading 'does not pluralize naively' error #414

What

An operationNames row whose methodName is not a valid C# identifier ending in Async (for example Reviewed, or Async alone) produces two errors for the same operation:

1. Naming / widget.list: method name 'Reviewed' must be a valid C# identifier ending in 'Async'. This is correct.
2. Operation / widget.list: the operation's names cannot be derived mechanically: the group does not pluralize naively. This is misleading.

The cause: SpecBinder.Bind collects validation and binding errors on one collector and throws only at the end (Generator/Binding/SpecBinder.cs:42-85). So the invalid curated row still reaches OperationPlanBinder. There, OperationNamePolicy.RouteMemberName returns null for a curated name without a usable Async suffix (OperationNamePolicy.cs:136-139), and OperationPlanBinder.cs:313-316 reports that null as a pluralization failure.

Why it matters

The second error names the wrong cause. The group pluralizes fine; the curated method name is the fault. An author who reads both errors is sent to look at group pluralization. The binding error output exists to prevent exactly this kind of misdirection.

Proposed fix

There should be one owner per fault. Either:

• OperationPlanBinder skips its mechanical-naming refusal when the curated row for that operation has already been refused; or
• RouteMemberName takes a curated name it cannot use as "no route name from this row", and the binder reports nothing more.

GEN-E3's operations PR (the error-map and facet ownership work, P46 and P42) is the natural home.

GEN-E2 Task B's literal matrix pins the current two-error behaviour (the Reviewed and Async rows in SpecBinderTests), so the fix shows up as a deliberate test change.

Found by the GEN-E2 Task B review and confirmed in its fix-up run (2026-10-17).