`unlint-non-existing-defect` benchmark lacks coverage for documents with `+unlint` metas, potentially missing regressions

I cannot tell whether objectionary/lints#1233 (or any future change to LtUnlintNonExistingDefect) is safe, because the only benchmark we have for that lint — the unlint-non-existing-defect entries in the README benchmark table — is driven by real-world bytecode-derived XMIR (com.sun.jna.*, org.apache.hadoop...FSNamesystem), none of which contain a single +unlint meta. That benchmark only measures the "no +unlint at all" fast path.

objectionary/lints#1233 changes the other path too: when +unlint metas are present, it now filters this.lints down to only the lints referenced by name before computing existingDefects(), instead of running the full list. We have no fixture with +unlint metas referencing defects that actually exist, so we have zero timing signal for that code path — no way to tell if it got faster, stayed the same, or regressed.

Start with the unlint-non-existing-defect entries in the README benchmark table and the LtUnlintNonExistingDefect implementation. Trace how +unlint metas select named lints and how existingDefects() is measured, then add a benchmark fixture containing +unlint metas that reference existing defects. Done means the README benchmark covers that path and provides timing for future regressions.