fix(desktop): allow Obsidian deep links in openExternal

[thefreenickmurray]

Summary

• Desktop chat rejected obsidian://… markdown links with Invalid external URL because openExternalUrl only allowed http: / https: / mailto:.
• Extract an explicit shell-open scheme allowlist (apps/desktop/electron/external-url.ts) and add obsidian: so vault deep links (e.g. obsidian://open?vault=…&file=…) launch the local Obsidian app when the OS has the protocol handler registered.
• Dangerous / unlisted schemes (javascript:, data:, file: via this path, IDE schemes not requested, etc.) remain denied. file: still goes through the existing shell.openPath path-hardening branch.

Test plan

• cd apps/desktop && npx vitest run electron/external-url.test.ts --project electron (5 tests pass)
• In Desktop chat, click a markdown link like [note](obsidian://open?vault=<vault-id>&file=Path%2FNote.md) with Obsidian installed → opens the note
• Click https://example.com → still opens in the browser
• Click javascript:alert(1) / bare unlisted custom scheme → still rejected (no OS handoff)

[alt-glitch]

This was generated by AI during triage.

Related: #75457 proposes a broader local-file and Obsidian response-link policy. This PR is the narrow shell.openExternal allowlist path only; maintainers should choose or consolidate the policy before merging.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(desktop): allow Obsidian deep links in openExternal

1. apps/desktop/electron/main.ts:1354 — the URL is parsed once for earlier checks, then parsed.toString() is re-parsed inside isAllowedShellOpenExternalUrl, and the helper only consults parsed.protocol. Passing the already-parsed parsed.protocol (or accepting a URL object) would avoid the serialize→re-parse round-trip and keep the two parse sites from drifting.
2. apps/desktop/electron/external-url.ts:75-80 — the allowlist gates on scheme only, so any obsidian:// URL (e.g. obsidian://open?vault=...&file=... pointing at arbitrary local files, or obsidian://new) is handed to the OS handler. Since Obsidian can navigate to local vault content, consider validating the host/action for obsidian: (only open with a vault param) or at least documenting in the file that the scheme alone is the security boundary.
3. No blocking issues — the test coverage (empty/null input, dangerous schemes, case-insensitivity, round-trip of http://127.0.0.1:5174/) is thorough and the regression case is well documented.