Dummies: give AnyDictionary a containment constraint and share the count facade

[Reefact]

Problem

AnyDictionary cannot inherit AnyCollection<…> (its element is a key/value pair, not a single item), so it re-implements the entire count facade verbatim — NonEmpty/Empty/WithCount/WithMinCount/WithMaxCount/WithCountBetween plus the RequireNonNegative/V helpers, ~60 lines copied from AnyCollection.cs:56-118 (AnyDictionary.cs:51-113). It also offers no Containing/ContainingAny at all — the only collection generator without a containment constraint. The test suite itself notes the gap (AnyCollectionTests.cs:161-163: "AnyDictionary has no Containing surface … cannot exercise the out-of-domain case directly").

The core reuse is right: keys run through the same CollectionState as AnySet, so cardinality gating, bounded draw, shuffle and comparer plumbing are shared. Only the fluent count facade is duplicated, and the containment surface is missing.

Impact

• Duplication / drift risk: a fix or message change to the base count family must be mirrored by hand into AnyDictionary, and one can be missed.
• API hole: a test cannot pin that a dictionary contains a particular key (or key/value), unlike every other collection.
• Coverage hole: the out-of-domain cardinality-credit path for dictionary keys is untestable through the public surface.

Direction

Two independent changes:

1. Extract the count facade into a shared helper over CollectionState (a private protected mix-in or an extension surface both AnyCollection and AnyDictionary delegate to) so the count algebra lives once.
2. Add ContainingKey(TKey) — routing to the key state's WithContaining, inheriting the out-of-domain cardinality credit for free — and optionally Containing(TKey, TValue) that pins the value for that key after generation. This also closes the coverage hole the suite comments on.

Acceptance criteria

• The count-constraint logic is defined once and shared by AnyDictionary and the AnyCollection builders (no verbatim copy).
• Any.DictionaryOf(keys, values).ContainingKey(k) produces a dictionary containing key k, with the same out-of-domain cardinality crediting as SetOf(...).Containing(...).
• Tests exercise ContainingKey inside and outside the key generator's domain, and the shared count facade for both surfaces.

Context

Surfaced by the 2026-07-20 architecture & design audit of the standalone Dummies library (doc/handwritten/for-maintainers/audit/2026-07-20-dummies-architecture-and-design-audit.md, §7.1/§8.2/§9; branch claude/dummies-architecture-audit-cru5aq).

---

Filed from the Claude Code session that produced the 2026-07-20 Dummies architecture & design audit: https://claude.ai/code/session_01GvrWFVoG74xiys3oyEft1G

[Reefact]

Delivered — both changes described here are merged into main:

• refactor(dummies): share the collection count facade across generators #285 — shared count facade: the NonEmpty/Empty/WithCount/WithMinCount/WithMaxCount/WithCountBetween algebra now lives once in an internal CountConstraints helper over CollectionState, which both the AnyCollection builders and AnyDictionary delegate to. The ~60-line verbatim copy is gone; public signatures, exception types and constraint labels are unchanged.
• feat(dummies): add ContainingKey to the dictionary generator #286 — AnyDictionary.ContainingKey(TKey): routes to the key state's WithContaining, inheriting the out-of-domain cardinality credit for free (the crediting already lives in CollectionState). Tested inside and outside the key domain, and the stale comment in ContainingOutsideDomainExtendsCardinality that noted the gap is refreshed.

All three acceptance criteria are met. The optional Containing(TKey, TValue) value-pinning overload was intentionally left out of scope; together with a generator-based ContainingAnyKey(IAny<TKey>) (for full parity with ContainingAny) it remains a possible future enhancement.

Closing as completed.

---

Generated by Claude Code