fix(whispering): Allow opener to access files in data directory on Linux

[Wartijn]

Summary

Add paths of the data directories to the permissions of opener:allow-open-path. For Linux the wildcard path can't be used for this, so without this change, the default directories for recordings and transformations can't be opened via the buttons that use plugin-opener.

Type of Change

• feat: New feature
• fix: Bug fix
• docs: Documentation update
• refactor: Code refactoring (no functional changes)
• perf: Performance improvement
• test: Test additions or changes
• chore: Maintenance tasks
• style: Code style changes

Related Issue

Closes #1200

Changes Made

• Added paths for opener:allow-open-path as described above. This is the same fix as feat(linux): add explicit file system permissions for app data directory #866, but for opener:allow-open-path instead of fs:scope
• Handled the where opening the directory throws a string instead of an Error object, which is what happened in this case. Now this will create a notification with the description "Not allowed to open path {path}" instead of "Unknown error"

Testing

For both the error handling and permission fix I tested this in these places:

• Recordings screen -> "Open recordings folder" button
• Transformations screen -> "Open transformations folder" button
• Settings -> Recording -> "Open output folder" button

Before fixing the permissions, clicking any of the buttons would show a notification showing "Not allowed to open path".
After fixing the permissions, clicking the button opens the default file explorer.

As for the checks below:

• I've only tested this on Linux, since it's a Linux specific issue. And since it only adds permissions it shouldn't break anything anyway
• I do quite a few console errors, but not more than before and not directly related to this problem. I'll create tickets and/or PRs for those issues

Desktop App Testing

• Tested on macOS
• Tested on Windows
• Tested on Linux
• Not applicable (web-only change)

General Testing

• Tested with multiple API providers (if applicable)
• Verified no API keys are exposed in logs or storage
• Checked for console errors
• Tested on different screen sizes (if UI change)

Checklist

• My code follows the project's coding standards (see CONTRIBUTING.md)
• I've used type instead of interface in TypeScript
• I've used absolute imports where applicable
• I've tested my changes thoroughly
• I've added/updated tests for my changes (if applicable)
• My changes don't break existing functionality
• I've updated documentation (if needed)

Screenshots/Recordings

Additional Notes