[Bug]: DeliverToAppSource ignores includeDependencies and packages additional dependency apps

AL-Go version

9.0

Describe the issue

We are using AL-Go for GitHub AppSource template v9.0.

Our app has the following dependency structure:
Advanced Package Mgt
├─ Customer License Management
└─ Detailed Inventory

The repository settings contain:

We expect only the Customer License Management dependency to be packaged into the generated .libraries.zip.

However, the generated libraries package still includes additional dependency apps which do not match the configured filter.

Repository Settings
"appDependencyProbingPaths": [
{
"repo": "EYNA-SOFTEAM/MKT-EYN-CUSTOMER-LICENSE-MANAGEMENT",
"version": "latest",
"release_status": "release"
},
{
"repo": "EYNA-SOFTEAM/MKT-EYN-DETAILED-INVENTORY",
"version": "latest",
"release_status": "release"
}
],
"deliverToAppSource": {
"productId": "ee0e0e94-831b-4d2a-926f-61c35368e72a",
"mainAppFolder": "EYN-Advanced-Package-Mgt",
"includeDependencies": [
"Eyna Softeam, S.L._Eyna Customer License*.app"
]
}

Observed Behavior
The Deliver workflow generates: Eyna Advanced Package Mgt._2.4.47.0.libraries.zip

Contents::
Eyna Customer License Management_1.0.2.0.app
Eyna Customer License Management_2.0.8.0.app
Eyna Detailed Inventory_2.0.15.0.app

Expected behavior

Generated .libraries.zip should contain only files matching:
Eyna Softeam, S.L._Eyna Customer License*.app

For example:
Eyna Customer License Management_2.0.8.0.app

or whichever matching files AL-Go considers valid.
Dependency apps that do not match the configured includeDependencies filter should not be packaged.

Question
Is includeDependencies expected to filter the content of the generated .libraries.zip?
If yes, this appears to be a bug.
If no, could you clarify the intended behavior and the supported way to exclude specific dependency apps from the AppSource libraries package?

The Deliver workflow log correctly reads and displays the includeDependencies setting, however the generated .libraries.zip still contains dependencies that do not match the configured pattern. This suggests that the filtering logic is either not applied when creating the library package or behaves differently than documented.

Steps to reproduce

1. Create an AL-Go AppSource repository using AL-Go v9.0.

2. Configure multiple dependency repositories using appDependencyProbingPaths:
   "appDependencyProbingPaths": [
   {
   "repo": "repoA",
   "version": "latest",
   "release_status": "release"
   },
   {
   "repo": "repoB",
   "version": "latest",
   "release_status": "release"
   }
   ]

3. Configure deliverToAppSource with a dependency filter:
   "deliverToAppSource": {
   "productId": "",
   "mainAppFolder": "",
   "includeDependencies": [
   "_*.app"
   ]
   }

4. Enable CI/CD delivery to AppSource.
   generateDependencyArtifact": true

5.Run the CI/CD workflow until the Deliver to AppSource stage is executed.

6.Inspect the generated artifacts:
Dependencies.zip
.libraries.zip

Additional context (logs, screenshots, etc.)

No response