fix(schema): use FQCN for core model classes to resolve PSR-4 deprecation

[Ibochkarev]

What does it do?

Use fully qualified class names (FQCN) for all core model classes in core/model/schema/modx.mysql.schema.xml. Replaces every short class name (e.g. class="modNamespace", class="modResource", class="modUser") with MODX\\Revolution\\* equivalents. Covers modNamespace, modPlugin, modPluginEvent, modSystemSetting, modMenu, modResource, modUser, modTemplate, modChunk, modSnippet, modCategory, modContext, modEvent, modFormCustomization*, modTemplateVar*, modUserGroup*, modAccess*, and all other mod* objects in the main schema.

Additionally, modX::loadClass() now normalizes short mod* names to FQCN at runtime. When legacy code or xPDO call paths pass short names (e.g. modResource, modAccessContext), they are converted to MODX\Revolution\* internally. A class_alias is created for backward compatibility. This avoids deprecation notices from getObject, getCollection, newQuery, and other paths that invoke loadClass before modAccessibleObject::load.

Why is it needed?

Short names in the schema cause the profiler and modX::loadClass() to trigger v3.0 deprecation warnings that tell users to replace references with MODX\\Revolution\\* for PSR-4 autoloading. Application code already uses modNamespace::class and equivalent; the warnings come from the schema-defined class attribute and the resulting xPDO map keys. Updating the schema to FQCN aligns metadata with PSR-4 and removes the deprecation notices. Runtime normalization in loadClass() handles remaining call paths that still pass short names.

How to test

Run the application with the profiler or deprecation log enabled; verify that deprecation warnings for mod* classes from this schema no longer appear. Optionally rebuild the model from the updated schema and confirm the map uses FQCN.

Related issue(s)/PR(s)

None.

[Mark-H]

I'm confused about the schema changes - all objects are already in the \MODX\Revolution package so this is already getting prepended as namespace when the model is built. It seems like this would cause that it to get doubled up.

Any deprecation warnings should come from specific usages using the short name, not the core schema. But as there's no issue linked or deprecation warning shown, it's unclear what specifically we're fixing.

The loadClass fix I could get behind but would want to test with third-party extras that have (perhaps unwisely so) used the mod prefix in their models.