fix: stop exporting deep-link URL handler

[webees]

Which issue does this PR fix?

No existing issue.

Refs #389. That PR moved the cloud login device-link URL to openUrl(...) so it opens in the user's system browser instead of being routed through Donut's profile selector. After that flow no longer needs the profile-selector path, handle_url_open should remain an internal deep-link/startup URL helper only, not a frontend-invokable Tauri command.

This also fixes the Rust CI failure reported by test_no_unused_tauri_commands, where handle_url_open was exported in generate_handler! but had no frontend invoke(...) caller.

How to test

1. Run pnpm format && pnpm lint && pnpm test.
2. Confirm test_no_unused_tauri_commands passes and reports all exported Tauri commands are used.
3. Review src-tauri/src/lib.rs and confirm handle_url_open is still called from deep-link/startup URL handling, but is no longer exported through tauri::generate_handler!.

Local checks run:

• cargo test tests::test_no_unused_tauri_commands -- --nocapture
• pnpm format && pnpm lint && pnpm test

Checklist

• Read CONTRIBUTING.md
• Ran pnpm format && pnpm lint && pnpm test locally and it passes
• I tested the changes myself by running the app locally
• Updated translations in all locale files (if UI text changed; no UI text changed)

AI usage

• I used AI to help write this PR

AI helped inspect the failing PR CI logs, relate the failure to #389, and prepare the minimal Rust cleanup. The final diff and checks were reviewed locally.

[github-actions]

This PR correctly removes handle_url_open from the Tauri command registry since it's only called internally (deep-link handler, startup URL processing) and never invoked from the frontend — fixing the test_no_unused_tauri_commands CI failure.

Code review: The diff removes #[tauri::command] and the generate_handler![] entry for handle_url_open. The function remains as a plain async fn and is still called directly at three sites in the setup closure (deep-link on_open_url, startup URL, and pending URL processing), so no dead-code issue. The function signature (AppHandle, String → Result<(), String>) works fine without the command macro since callers already use it as a direct Rust call. No frontend invoke("handle_url_open", …) exists post-#389, and handle_url_open isn't in the mcp_only_commands allowlist, confirming it has no programmatic callers either. No translation or UI changes involved.

PR looks good — minimal and correct.

[zhom]

Hi there :) Thanks for the PR. I'll close it as I have already fixed it locally, just wasn't able to publish it as I have a large update coming up. Thank you!