perf: index-based constraint key scheduler for O(k) lookups

[thomhurst]

Summary

• Replace O(n) full queue drain with new `WaitingTestIndex` that maps constraint keys to waiting tests
• When keys are released, only tests waiting on those specific keys are examined (O(k) where k = released keys)
• Eliminates O(n²) total overhead for n constrained tests — each completion previously scanned the entire waiting queue
• `WaitingTestIndex` maintains a bidirectional index: key→tests and test→keys for efficient add/remove

Test plan

• Verify constraint key scheduling still respects key exclusivity
• Verify priority ordering is maintained for waiting tests
• Verify tests with multiple constraint keys are handled correctly
• Run full engine test suite

🤖 Generated with Claude Code

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

---

Review highlights:

This PR represents an excellent algorithmic optimization with strong attention to performance principles:

Algorithmic improvement: The shift from O(n²) total overhead to O(k) lookups is a significant performance win. Instead of scanning all waiting tests on every completion, only tests waiting on the specific released keys are examined.

Design approach: The bidirectional index (WaitingTestIndex) is well-architected:

• Clean separation of concerns with explicit documentation of locking requirements
• Efficient deduplication using HashSet.UnionWith
• Manual loops instead of LINQ to minimize allocations
• Priority ordering maintained through sorting candidates

Concurrency correctness: All access to the index is properly serialized under lockObject. Moving the Add call inside the lock (vs. the old ConcurrentQueue.Enqueue outside the lock) is actually a correctness improvement for the indexed approach.

CLAUDE.md compliance: The code adheres to all applicable rules:

• Performance First: Explicit allocation-conscious decisions (e.g., "Use a simple list + sort rather than a SortedSet to avoid per-element allocation")
• Modern C#: Uses required properties and target-typed new()
• AOT Compatible: No reflection, only standard collections
• Thread safety: Proper synchronization documented and enforced

The implementation demonstrates the kind of measured, performance-conscious design that aligns well with TUnit's principles.