When a mod supplies an `EntityPersistenceConfig` whose rule matches a prefab that a vanilla persistence config also matches, the vanilla config is always selected, regardless of the mod config's `Priority` and regardless of match specificity. This makes it impossible for a mod to adjust how a vanilla-covered prefab persists (e.g. to add a missing serializer), even though the config format looks designed for exactly that.
## Steps to reproduce
1. Create a mod persistence config for `ArsenalBox_Base.et` (or a concrete descendant like `E_ArsenalBox_US.et`) with the same `PrefabPersistenceConfigRule` shape as vanilla's `Storage/Arsenal.conf` plus one extra serializer (`BaseInventoryStorageComponentSerializer`).
2. Register it in the mission's persistence settings; set `Priority` high (tested 30000) and low (tested 1); try both the base prefab and a deeper concrete-prefab match.
3. Spawn the box on a persistent server, save, decode/inspect the save.
## Observed
In every tested combination the box's record lands under the **vanilla** config (vanilla's collection, vanilla's serializer set). The mod config is never selected; `Priority` visibly does not decide the competition, and a more specific prefab match does not either. No log output indicates which config won or why.
Combined with #ARMD-13 (scripted rules never consulted) and the fact that runtime `SetConfig` re-writes make existing records unreadable, there is **no working path** for a mod to alter persistence behaviour of a vanilla-matched prefab.
If this is intended it should fail loudly if a modder tries to insert it's own config over a vanilla one, but currently we have no control over persistence of vanilla objects and are forced to create custom prefabs instead.