fix(cli): prevent panic when askpass broker is not initialized

[themavik]

Summary

• but pull (and other CLI operations requiring SSH auth) panics with askpass broker not initialized when running outside the GUI
• Root cause: the global askpass broker is only initialized in the Tauri GUI setup path; the CLI code path skips initialization
• Fix: get_broker() now returns Option instead of panicking, and all call sites gracefully handle the uninitialized case

Problem

The askpass broker handles SSH credential prompts (passphrase, auth tokens) by forwarding them to the GUI as Tauri events. It's stored in a global static and initialized in crates/gitbutler-tauri/src/main.rs during the Tauri setup hook.

When the same binary runs as a CLI (but pull, but push, etc.), the early-return at the CLI entry point skips the Tauri setup, leaving the broker uninitialized. Any git operation that triggers an SSH prompt then calls get_broker() which panics:

thread '' panicked at crates/gitbutler-repo-actions/src/askpass.rs:29:45:
askpass broker not initialized

Fix

get_broker() now returns Option<&'static AskpassBroker> instead of unwrapping:

All 4 call sites updated to handle None:

• handle_git_prompt_push — returns None (auth fails gracefully)
• handle_git_prompt_fetch — returns None (auth fails gracefully)
• handle_git_prompt_clone — returns None (auth fails gracefully)
• submit_prompt_response — logs warning and no-ops

This means CLI operations that don't need credentials continue to work normally, and operations that need credentials fail with a proper authentication error instead of crashing the process.

Test plan

• Verify but pull with a public repo works without panic
• Verify but pull with a password-protected SSH key returns an authentication error instead of panicking
• Verify the GUI askpass flow still works (broker is initialized, prompts appear as before)
• Run cargo clippy -p but-api — passes clean

Fixes #12279

[vercel]

@themavik is attempting to deploy a commit to the GitButler Team on Vercel.

A member of the Team first needs to authorize it.

[esskayesss]

... and operations that need credentials fail with a proper authentication error instead of crashing the process.

from @Byron's comment
Maybe we don't call init when we should or when we did previously?
Maybe we never initialised it.

but why don't we also initialize the broker at the correct time as was pointed out in @Byron's comment?