The persistence system's config rules (`PersistenceConfigRule`) look like a scriptable extension point: the class is visible to script and a subclass with an overridden `IsMatch` compiles and binds in an `EntityPersistenceConfig` `.conf` without any error. But the engine **never calls a script-defined rule**. Only the native generated rule classes (e.g. `PrefabPersistenceConfigRule`) are evaluated. A scripted rule silently never matches, so the config it guards is silently never selected.
## Steps to reproduce
1. Subclass `PersistenceConfigRule` in script, override `IsMatch`, add a `Print` in it.
2. Bind the rule in an `EntityPersistenceConfig` in a persistence configuration `.conf` (any priority).
3. Load a world where entities should match; also force re-matching via `ReloadConfig()` on candidate entities.
## Observed
`IsMatch` is called **zero** times — measured across a full world load, initial tracking of ~hundreds of characters, and 300 forced `ReloadConfig()` re-matches with instrumentation. No warning or error is emitted anywhere; the config is simply never chosen.
## Expected
Either scripted rules are evaluated like native ones, or binding a scripted rule class in a persistence config is rejected loudly (config-load error / log warning) and the limitation is documented.
## Impact
Any mod feature built on a scripted match rule fails silently with "entities just don't persist" as the only symptom, which is expensive to diagnose (ours took an instrumented run to prove the rule was never reached).