Generator: CurationValidator derives the handle placement separately from the binder #364

What

CurationValidator.ValidateOperationNames (added in #361) decides whether a list operation sits on a handle client by re-deriving it: the group's curated placement is Client, and one of the operation's path parameters is the group's handle parameter. It needs that to compare a row against the mechanical method name. OperationPlanBinder derives the same fact for binding (around OperationPlanBinder.cs:305), and CurationValidator already spells the handle-parameter match at other sites (around lines 244-262).

Why it matters

Two derivations of one fact can drift. If the binder's handle rule changes and the validator's copy does not, the redundant-row refusal compares against the wrong mechanical name. It would then refuse a needed row, or accept a redundant one.

Proposed fix

One owner for "is this operation bound on its group's handle", used by both the binder and the validator. This fits GEN-E2 (curation as one typed row contract), which is moving the row checks onto shared machinery anyway.

Found by the lead's deep read of #361 (2026-10-16).