📝 Document why open universes are rejected

Add a README Caveats subsection with user-facing guidance for the two
open-universe shapes: parse external input at the boundary down to a
finite union, or use a runtime Map registry for extensible domains.
Point the finite-universe bullet at it, and point the rejected
fix/open-universe-* entry in development/library.md back at the new
guidance, so rule and decision cross-reference without duplicating each
other.

development/library.md

@@ -167,7 +167,9 @@ Extract<T, Stringified<T>>` catches numeric collisions too.
   non-self-referential parameter type (`{ [K in keyof H]: … R … }` gives
   `unknown`); an F-bounded guard referencing `keyof Handled` in `Handled`'s own
   constraint sees the constraint, not the map; all handlers share one `R` (only
-  the fallback widens it); `IsLiteral` is the finite-literal predicate.
+  the fallback widens it); `IsLiteral` is the finite-literal predicate. The
+  user-facing consequence — open universes are a parsing or registry concern,
+  not a dispatch one — is guidance in README § Why open universes are rejected.
 - **`Member<T, K>` without the gate:** sound, but a colliding handler gets a
   union and `1 | "1"` stays one runtime key.
 - **A round-trip injectivity gate** (`IsEqual<T, PatternParam<PatternKey<T>>>`):