fix(core):Skip pruned Set entries to prevent panic in unique predicate

[gooohgb]

We encountered a panic issue caused by the @unique directive and found it related to https://github.com/hypermodeinc/dgraph/issues/9437
After review, I determined that the root cause lies in the mismatch between the updateMutations pruning logic and the @unique validation. Specifically:

addQueryIfUnique executes before updateMutations, generating uniqueVars entries based on all mutation predicates.

Later, updateMutations may prune some of those mutations based on @if conditions, setting their .Set to nil.

However, the unique-check logic in verifyUniqueWithinMutation does not account for pruned mutations, and still attempts to access entries from .Set, leading to a nil dereference and index out-of-range panic.

But when a mutation has only one conditional clause, this line:

if len(qc.gmuList[gmuIndex].Set) == 0 { continue }
effectively bypasses the faulty access.

When there are multiple conditional mutations, due to uniqueVars being a map, the iteration order is random. This randomness causes the issue to appear intermittently.

For unit testing, I directly copied the test case provided by @matthewmcneely to reproduce the panic reliably.

[mangalaman93]

Thank you for the PR! The test fails, so please check. This is not the right solution.

[matthewmcneely]

@gooohgb See #9450 for a more complete sanity check in verifyUniqueWithinMutation and a much simpler test that's a lot easier to grok. That PR builds upon your initial attempt, so would welcome your review.

[gooohgb]

@gooohgb See #9450 for a more complete sanity check in verifyUniqueWithinMutation and a much simpler test that's a lot easier to grok. That PR builds upon your initial attempt, so would welcome your review.

@matthewmcneely The new PR LGTM — closing mine now.