Allow Face API edge specifiers to preserve grouped face references (multiple faces from region->extrude)

[Irev-Dev]

The region-derived tag case exposed a gap in the lower-level face API shape.

In KCL, this is a reasonable thing for users to write:

edges = [
  {
    sideFaces = [band.tags.circle1, capStart001],
    endFaces = [band.tags.line1]
  }
]

The awkward bit is that band.tags.circle1 can resolve to more than one concrete swept face after region() and extrude(). Today the modeling-commands edge specifier only has flat face ID arrays, so KCL has to expand that logical KCL reference into multiple flat engine EdgeSpecifier payloads.

That works for the broad case and for endFaces, because the engine still resolves each candidate payload. It is less ideal for index, because index is supposed to be engine-side disambiguation. KCL should not consume it locally. For now, KCL expands the payloads and forwards index through to the engine payloads unchanged.

The more complete API shape would let each side/end face entry be a named object that can hold one or more concrete IDs. Something along these lines:

{
  "sideFaces": [
    { "ids": ["circleFaceA", "circleFaceB"] },
    { "ids": ["capStartFace"] }
  ],
  "endFaces": [
    { "ids": ["line1Face"] }
  ],
  "index": 0
}

The important distinction is that each object is one logical face reference. Sometimes that logical reference maps to one concrete face ID, sometimes it maps to more than one. This preserves the grouping that is currently lost in a flat FaceId[].

Once modeling-commands and engine support that shape, KCL should stop expanding this case into multiple flat EdgeSpecifiers and instead pass the grouped logical face references through as a single topology query. That would make index unambiguously engine-side again and gives us room to add more fields later without another API-breaking change.

[Irev-Dev]

The reverse point-and-click path needs special attention. The engine does not necessarily need to return grouped logical face references, because a click selects one concrete edge. But it does need to return a payload that remains specific after modeling-app converts concrete face IDs back into KCL tags. If one returned side face corresponds to a region-derived tag that can expand to multiple concrete faces, then sideFaces alone may be under-specified in generated KCL. In that case the selection payload should include endFaces or, as a final fallback, index, so the generated KCL resolves back to the clicked edge. Today QueryEntityType appears to reason over concrete B-rep topology only, so we need to confirm whether it can access enough region/sweep provenance to know when this extra disambiguation is required.