scheduler.no_bundle_entity_type_settings.* schema is a bare mapping, not a config_object

Problem/Motivation

I screwed up. The schema added in #3355087: Support for non-bundle entity types for non-bundle entity type settings:

  scheduler.no_bundle_entity_type_settings.*:
    type: scheduler_third_party_settings

scheduler_third_party_settings is type: mapping — designed to validate third-party settings nested inside a host config entity. But scheduler.no_bundle_entity_type_settings.{entity_type_id} is a standalone, top-level config object, so its type should be config_object.

Because it's a bare mapping, the schema has no _core or langcode keys. Those are only defined on the config_object base type (core.data_types.schema.yml).

Consequence: a module that wants to ship sensible defaults for its non-bundle entity type via config/install (e.g. mymodule/config/install/scheduler.no_bundle_entity_type_settings.my_entity.yml) cannot. ConfigInstaller always writes _core.default_config_hash to installed config (ConfigInstaller.php ~line 395). With strict config schema checking on (every kernel/functional test, config validation tooling), this throws:

  Schema errors for scheduler.no_bundle_entity_type_settings.my_entity with the following errors:
  scheduler.no_bundle_entity_type_settings.my_entity:_core missing schema

So integrators are forced to create the config programmatically in hook_install() to dodge the installer (and langcode too). The settings form works fine because it set()s only the scheduler keys.

Steps to reproduce

1. Register a Scheduler plugin for a bundleless entity type.
2. Ship config/install/scheduler.no_bundle_entity_type_settings..yml with the default keys.
3. Install the module in a kernel test (or any context with ConfigSchemaChecker active).
4. SchemaIncompleteException: ... :_core missing schema.

Proposed resolution

Type the standalone config as a config_object so it inherits _core/langcode, while keeping the same scheduler keys. e.g.:

  scheduler.no_bundle_entity_type_settings.*:
    type: config_object
    label: 'Scheduler no-bundle entity type settings'
    mapping:
      expand_fieldset:
        type: string
        label: '...'
      fields_display_mode:
        type: string
        label: '...'
      publish_enable:
        type: boolean
      # ... remaining keys from scheduler_third_party_settings

Maybe we can re-use the mapping still while making sure it's a config object

AI helped me draft this after discovering in https://git.drupalcode.org/project/ai_context/-/merge_requests/168