Block PHP object injection when decoding term descriptions

[GaryJones]

Summary

Edit Flow stores pseudo term-meta (custom-status position and viewability, user-group membership, and similar) as a base64-encoded serialized array tucked into a term's description field, and read it back through the shared EF_Module::get_unencoded_description() helper using maybe_unserialize( base64_decode( ... ) ). Because maybe_unserialize() will happily instantiate any object encoded in the payload, that helper was a PHP object-injection surface, and the callers only inspect the result with is_array() after the unserialise has already run, so they could not prevent an object being constructed.

The decode is now gated with is_serialized() and uses unserialize() with array( 'allowed_classes' => false ), so no object can ever be instantiated. A plain, unencoded description still passes through unchanged, and the encode side is untouched, so existing stored data continues to read correctly with no migration.

An alternative was to migrate the format to JSON, but allowed_classes => false fully neutralises the object-injection threat with zero back-compat risk and without leaving a permanent legacy read path behind, so that is the route taken here.

Test plan

• composer cs and parallel-lint pass on the changed files.
• Two integration tests added and passing: a legitimate encoded array round-trips unchanged, and a serialized object payload is not instantiated as its class. The full ModuleTest class passes.

Fixes VIPPLUG-9.