We should consider reworking the IdLookupViaIndex iterator being introduced in SERVER-83760 to add support for non-_id, unique indexes. It makes sense to separate this case from the non-unique index case because the unique index iterator should be simpler (can use SortedDataIndexAccessMethod::findSingle() to look up the matching record, does not need to support getting a "next" record if shard filtering filters a document out, etc).

It might be hard to support all unique indexes in the fastest code path (saw some complications relating to collation and/or dotted paths during SERVER-86237). These more complicated cases can use the more general iterator instead.