perf(curation): index blocklist rules by literal name

[devitway]

Closes #953.

What

BlocklistFilter::evaluate walked every rule and ran three glob_match calls on each, for every artifact download. Free for a hand-written file of tens of rules; not free once the file is generated.

The allowlist next door has always been an O(1) map. This gives the blocklist the same treatment for the rules that allow it: a rule with a literal name goes into a hash bucket, a rule whose name is a pattern stays in a linear tail. A generated blocklist is almost entirely the former, so the tail stays in the tens.

The part that needed care

First match in file order wins, and that choice is visible: it decides which rule's reason a client reads in the 403. Probing the map and then the tail would silently reorder that.

So both collections index into one rules vector and the winner is chosen by original position. Because globs is ascending, the scan stops as soon as no remaining pattern can precede an exact rule that already matched.

Measured on a polygon

500 requests per run through a single curl process — so process spawn is not in the number — three runs each, same cached tarball, local storage.

build	rules	ms/request
main	10	0.113
main	197 314	4.237
this branch	10	0.124
this branch	197 314	0.119

The scan cost does not shrink, it disappears: with the index, 197k rules cost the same as ten. main's 197k numbers were stable across runs (4.175 / 4.217 / 4.237) — the cost is per-request, not a warm-up artifact.

Equivalence, on the real file

Not a fixture: the actual 197,314-rule blocklist. 305 packages sampled from it plus five well-known names, run against both builds — 300 blocked, identical status and identical response body everywhere. (One package initially differed; it was a transient upstream fetch failure on the baseline, 200 on both on retry.)

At the filter level a differential test pins the same property: an 84-case matrix of registries × names × versions over deliberately overlapping literal and pattern rules, comparing the indexed lookup against the naive scan it replaces — including which rule wins. Flip-verified: disabling the index-order merge turns it red with indexed lookup disagreed with the naive scan for Npm left-pad@None.

Plus three targeted tests: earlier rule wins regardless of shape, a bucketed rule still narrows on registry and version, and duplicate literal names keep file order.

Full suite: 63 lib + 1792 bin + 6 doc, zero failures. cargo fmt --check and cargo clippy -p nora-registry --all-targets -- -D warnings clean.

Correction to the issue

#953 quoted +3.8 ms against a 5.4 ms baseline. That baseline was measured with one curl process per request and was dominated by process spawn. The real per-request cost is ~0.12 ms and the scan adds 4.1 ms on top of it — the delta was right, the baseline was not. Numbers above are the corrected measurement.

Where the priority came from

Honestly: from Dozor, whose proactive mode generates exactly this kind of file. The limit is NORA's own, though — curation is designed to be file-driven and GitOps-managed, and a blocklist that only performs at hand-written scale quietly caps the feature.

[github-actions]

🐳 Test image pushed: ghcr.io/getnora-io/nora:pr-960

docker pull ghcr.io/getnora-io/nora:pr-960
docker run --rm -p 4000:4000 ghcr.io/getnora-io/nora:pr-960