Libraries in libraries config key refused with "Path not authorized" since 31.4.4

Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Describe the bug Since the read-path authorisation added for GHSA-fjgc-8xgj-rvh4 (31.4.4), shape libraries declared with a local file URL in the libraries configuration key no longer load. draw.io shows "Path not authorized". The 31.4.4 release notes state that libraries declared in the configuration still load, but this only works for some configuration keys, not for libraries.

Cause: collectConfigPaths() in src/main/electron.js collects templateFile, customTemplates, defaultCustomLibraries, customFonts, defaultFonts and fontCss, but not libraries[].entries[].libs[].url. These URLs are still loaded through the readFile IPC (via the Editor.prototype.loadUrl override in ElectronApp.js), so assertReadablePath() refuses them.

Suggested fix: in collectConfigPaths(), also pass config.libraries[].entries[].libs[].url to addUrl().

To Reproduce Steps to reproduce the behavior:

1. Save any shape library file to C:\drawio-test\test.xml
2. Go to Extras → Configuration and set:

   {"libraries":[{"title":{"main":"Test"},"entries":[{"id":"test","title":{"main":"Test"},"libs":[{"title":{"main":"Test"},"url":"file:///C:/drawio-test/test.xml","prefetch":true}]}]}]}

1. Click Apply, then open More Shapes and enable "Test"
2. See error "Path not authorized"

Expected behavior The library loads in the left panel, as it did in 31.1.8 (local library paths in the configuration have been supported since the fix for #1278).

draw.io version (In the Help->About menu of the draw.io editor):

• draw.io version 31.4.5 (last working version: 31.1.8)

Desktop (please complete the following information):

• OS: Windows 11

Additional context This affects setups where shared shape libraries are provided as local files and added through the configuration. Paths declared via defaultCustomLibraries are authorised, so extending the same handling to libraries would restore the previous behaviour.