Refactor IndexMatcher control flow to reduce CodeQL complexity hotspots

[Copilot]

IndexMatcher was flagged for elevated cyclomatic complexity, with forEachMatch called out as the primary hotspot and the deepest nesting around candidate match evaluation. This change reduces branching depth and conditional nesting in-place, without restructuring via helper extraction.

• forEachMatch: flatten candidate resolution and fallback evaluation

  • Replaced nested condition blocks with guard-continue flow when discriminant values are missing/invalid.
  • Kept discriminant lookup + full matches(...) verification semantics unchanged.
  • Preserved separate iteration over unclassified and function matchers while removing unnecessary per-call allocations.

• add / remove: simplify classification branches

  • Converted nested object/discriminant checks into early-return paths.
  • Kept matcher routing behavior identical:
    • function matchers → functionMatchers
    • object matchers with discriminant → lookup table
    • everything else → unclassifiedMatchers

• Behavioral intent

  • No algorithmic redesign; this is a control-flow refactor to lower complexity/readability risk in the existing matcher pipeline.

for (const propPath of this.properties) {
    const docValue = getPropertyAtPath(document, propPath);
    if (docValue === undefined || docValue === null || typeof docValue === 'object') continue;

    const indexSet = this.table.get(propPath)?.get(String(docValue));
    if (!indexSet) continue;

    for (const indexName of indexSet) {
        if (matches(document, this.matchers.get(indexName))) iterationHandler(indexName);
    }
}

[coveralls]

coverage: 98.106% (+0.1%) from 97.964% — copilot/reduce-complexity-indexmatcher into main

[albe]

@copilot where is the reduced code coverage coming from? If the logic didn't change coverage shouldn't be affected, no?

[Copilot]

@copilot where is the reduced code coverage coming from? If the logic didn't change coverage shouldn't be affected, no?

Good catch — coverage dropped because the refactor changed how c8/istanbul instruments branches, even though behavior stayed the same. In IndexMatcher.js the new guard-style early returns/continues in add/remove/forEachMatch created separately counted branch paths, and some of those specific paths are not exercised by current tests (currently reported around lines 95-112). So this is a branch-coverage accounting change from control-flow shape, not a logic regression. If you want, I can add focused tests for those missing paths to restore the previous coverage level.

[albe]

@copilot yes add new tests that covers this code branch to keep coverage same or even improve it

[Copilot]

@copilot yes add new tests that covers this code branch to keep coverage same or even improve it

Added focused tests in commit 33e19d5 to cover the missing IndexMatcher.remove() branches (unknown index, function matcher, non-object matcher, and object matcher without discriminant). Coverage is now improved and IndexMatcher.js reports 100% statements/branches/functions/lines.