Initialization with PSR-11 container relies on an implicit `config` entry

[opengeek]

When xPDO is initialized with a PSR container, the configuration needed to bootstrap the instance is expected to be available under a specific container entry named config.

This creates an implicit and fragile contract:

• the constructor accepts a generic ContainerInterface
• but successful initialization depends on a specific service/key being present
• that requirement is not obvious from the type alone
• if the expected entry is missing, initialization falls back in a way that can hide the actual problem

As a result, passing a container is ambiguous:

• is the container meant to provide services only?
• is it also expected to act as the source of xPDO configuration?
• what exact data must it contain for xPDO to initialize correctly?

Why this is a problem

• Implicit API contract: a generic PSR container does not communicate that it must contain xPDO initialization data under a specific name.
• Tight coupling to a magic key: initialization behavior depends on a hard-coded entry name rather than an explicit contract.
• Poor discoverability: users can pass a valid container and still get incorrect or incomplete initialization without a clear signal about what is missing.
• Mixed responsibilities: the same argument is being used as both a service container and a configuration source.
• Harder interoperability: containers from different applications/frameworks may not expose configuration in the same way.

Expected behavior

The API for initializing xPDO should make the required initialization data explicit and predictable when a container is involved.

Actual behavior

Initialization with a container depends on an undocumented/implicit assumption about a specific configuration entry inside that container.

Impact

This can lead to:

• confusing constructor usage
• runtime surprises when integrating with existing PSR containers
• harder-to-document initialization patterns
• uncertainty for users adopting dependency injection with xPDO

Reproduction

1. Create or use any valid ContainerInterface implementation.
2. Pass it to xPDO during initialization.
3. Do not define the expected config entry in that container.
4. Observe that xPDO does not have the expected initialization properties available, and the failure mode is not clearly communicated.

Additional context

This issue is about the API contract and initialization behavior, not about any specific framework container implementation.