docs: codify the Override rule in CONTRIBUTING and CONTEXT

Resolves decision 10's reservation on maintainer word: the 3+2/5 cap
numbers stay as written — across the full prune they held everywhere
except a handful of explicit overrides — and the override practice
itself becomes a written rule: the maintainer may exceed any limit
for a specific entry or use case by explicit decision, case-by-case,
carrying no weight for submissions. CONTEXT.md gains the matching
Override vocabulary entry.

Co-Authored-By: Claude <noreply@anthropic.com>

CONTEXT.md

@@ -50,6 +50,9 @@ _Avoid_: Rising Star (old lane name), Hidden Gem (old lane name — concept remo
 **Second Tier**:
 A Challenger slot holding a demoted incumbent instead of a rising successor — a former Obvious Choice or fading community standard an Audit kept below the current Obvious Choices (clickhouse-driver behind the official client, dogpile.cache and django-cacheops behind cachetools and diskcache, django-haystack in Search). It counts against the two Challenger slots and is marked by position like any Challenger; the adoption-trajectory bar gates only new admissions, not demotions.
 
+**Override**:
+A maintainer decision, made in an Audit and explicitly recorded, that keeps an entry or use-case shape past a written limit — the activity line, the stability bar, a cap, or a structure rule. Case-by-case: an Override never loosens the written rule for any other entry, and submitters cannot cite one.
+
 **Split**:
 Maintainer-only restructuring of an oversized Use Case into finer Use Cases (new Subcategories), considered before any trimming when the size reflects genuinely distinct jobs. A submitter's entry PR can never perform a Split.
 

CONTRIBUTING.md

@@ -23,6 +23,8 @@ Each use case lists at most:
 
 Hard maximum: 5 entries per use case. This is a qualitative bar first and a numeric backstop second — most use cases should carry fewer.
 
+**Overrides**: the maintainer may exceed any limit on this page — the caps, the activity requirement, the stability requirement — for a specific entry or use case by explicit decision. An override is case-by-case; it does not loosen these rules for submissions, and citing one in a PR carries no weight.
+
 **Displacement**: once a use case is at its cap, the only way in is to name the entry your project replaces and argue that yours does that entry's job better. One in, one out.
 
 **Standard library**: a standard-library module is listed only where the stdlib is itself the obvious choice for the use case (tomllib yes, unittest no).