.moodle-plugin-ci.yml from subplugins is not read when running checks on the parent plugin

[marinaglancy]

When running moodle-plugin-ci checks (e.g. phpcs) on a plugin that contains subplugins, only the .moodle-plugin-ci.yml from the main plugin is read. The .moodle-plugin-ci.yml files in subplugin directories are ignored.

This forces the main plugin to declare notPaths entries for every subplugin's third-party library, even when the subplugins are independently developed and maintained in separate repositories. In my case, the main plugin itself has no third-party libraries and would not need a .moodle-plugin-ci.yml at all — the only reason it exists is to work around this limitation for its subplugins.

Example directory structure

admin/tool/realtime/                   ← main plugin (no vendor, no third-party libs)
├── .moodle-plugin-ci.yml              ← only exists to suppress subplugin vendor errors
├── db/
│   └── subplugins.json
├── version.php
│
└── plugin/                             ← subplugins directory
    ├── centrifugo/                     ← subplugin (separate git repo)
    │   ├── .moodle-plugin-ci.yml       ← IGNORED by moodle-plugin-ci
    │   ├── vendor/                     ← causes check failures
    │   │   └── centrifugal/phpcent/
    │   ├── thirdpartylibs.xml
    │   └── version.php
    │
    ├── pusher/                         ← subplugin (separate git repo)
    │   ├── .moodle-plugin-ci.yml       ← IGNORED by moodle-plugin-ci
    │   ├── vendor/                     ← causes check failures
    │   │   └── pusher/pusher-php-server/
    │   ├── thirdpartylibs.xml
    │   └── version.php
    │
    └── phppoll/                        ← subplugin (no third party libs)
        └── version.php

Current workaround

The main plugin's .moodle-plugin-ci.yml must list every subplugin vendor directory, even though the main plugin itself has no third-party dependencies:

filter:
  notPaths:
    - plugin/pusher/vendor
    - plugin/centrifugo/vendor

Problem

This workaround has several downsides:

1. Subplugins are often independently maintained in their own repositories. The main plugin shouldn't need to know about the internal structure of its subplugins.
2. The main plugin's config must be updated every time a new subplugin with a vendor directory is added.
3. Subplugin authors can't control their own CI configuration — their .moodle-plugin-ci.yml is only effective when running CI on the subplugin alone, not when running it as part of the parent plugin.
4. The main plugin is forced to have a .moodle-plugin-ci.yml it otherwise wouldn't need, solely to work around subplugin vendor issues.

Expected behaviour

When running checks on a plugin, moodle-plugin-ci should also read and merge .moodle-plugin-ci.yml files found in subplugin directories. At minimum, notPaths from subplugin configs should be respected.

The implementation doesn't even need to be aware of the subplugin type structure — it could simply find all .moodle-plugin-ci.yml files in all subdirectories of the plugin and respect them.