GHSA-2223-f22x-24cq

### Impact Affected versions of Winter CMS allow authenticated backend users with the `cms.manage_assets` permission ("Manage website assets - images, JavaScript files, CSS files") to disclose arbitrary files readable by the PHP process by placing an `=include` / `=require` directive in a theme JavaScript asset. `Winter\Storm\Parse\Assetic\Filter\JavascriptImporter` processes `=include` / `=require` directives found in comment blocks of JavaScript assets passed through `System\Classes\CombineAssets`. The directive target was resolved relative to the including file's own directory with `realpath()` and inlined into the combined output with no confinement check, so a directive such as `=include ../../../.env` escaped the theme's asset tree and inlined an arbitrary server-readable file. The only restriction was that the target had to have a file extension, since extension-less names had `.js` appended to them. Because the combined output is served through the `combine/{file}` route, which performs no authentication or authorization checks, the disclosed contents then became readable by **unauthenticated** visitors at a stable URL as soon as the asset was referenced by any template. The leaked content includes any file the web process can read, most importantly the application `.env` file (disclosing `APP_KEY` and database credentials). Text files were disclosed intact; binary content was mangled by the minification pipeline. This is the JavaScript-importer counterpart of GHSA-58fp-mcx6-7qf9 (Local File Inclusion through LESS `@import` directives) and of CVE-2023-52085 / GHSA-2x7r-93ww-cxrq — the same vulnerability class reached through a different asset combiner filter. To actively exploit this issue, an attacker would need an authenticated backend account with the `cms.manage_assets` permission. By default this permission is assigned to the built-in Developer role. The Winter CMS maintainers strongly recommend that the `cms.manage_assets` permission only be rese