Feat: start TUI immediately with async baresip connection

[jakobhellermann]

Summary

Previously, tui::run blocked on wait_for_port (polling baresip's ctrl_tcp port for up to 5s) and TcpStream::connect before the terminal was set up. If baresip was slow to come up, the previous screen stayed visible and the UI was unresponsive for a moment; if it never came up, the user got an opaque error after the timeout.

This change starts the TUI immediately and connects to baresip asynchronously in the background:

• New run_baresip_io async task: retries TcpStream::connect for up to 10s, then spawns the existing reader/writer tasks.
• New AppEvent::BaresipConnectFailed { reason } event surfaces connect-timeout failures in the UI as RegStatus::Failed with the reason (including the baresip log path).
• Status bar's Unknown (now "Connecting") state uses the attention color so the in-progress connection is visible.
• Removed the now-unused wait_for_port helper and synchronous port-readiness check from Baresip::spawn.
• Added a unit test covering the connect-failure path (asserts BaresipConnectFailed is emitted with port and log path in the reason).

Test plan

• cargo build clean
• cargo test passes (incl. new connect_failure_emits_baresip_connect_failed)
• Manual: start ringo with a valid profile — TUI shows "Connecting" briefly, then transitions to "Registering" → "Registered"
• Manual: start ringo with no baresip available (port sabotaged) — TUI shows "Connecting" for 10s, then "Failed: baresip unreachable: ..." with log path

[steinbrueckri]

any update on this @davidborzek?

[davidborzek]

lgtm