refactor: add strong typing to AddMint and PeekMint UI messages

[tvolk131]

Change the type within Message::AddMint and Message::PeekMint from String to a new MintConnectionInfo type, which is an enum containing either a MintUrl or InviteCode. This forces the parsing of connection strings to be moved from the message processing code to the message creation code. This has two positive effects:

• Removes the need to handle un-parseable strings in the message processing code (see the removal of the "Can't add mint" and "Can't preview mint" toasts)
• Forces the "Preview" and "Join Mint" buttons to use .on_press_maybe(), which disables the buttons unless a valid MintConnectionInfo can be parsed

Essentially, rather than allowing for the "Preview" and "Join Mint" buttons to be pressed at any time, but presenting error toasts if pressed with an unparseable value, we now disable these buttons from even being pressed unless a parseable value is entered

[Copilot]

Pull Request Overview

This PR refactors the AddMint and PeekMint UI messages to use strong typing instead of raw strings. The key change is introducing a new MintConnectionInfo enum that can parse either a MintUrl or InviteCode, moving validation from message processing to message creation time.

• Introduces MintConnectionInfo enum with parsing logic
• Updates UI buttons to use .on_press_maybe() for conditional enabling based on valid input
• Removes error handling for invalid connection strings from message processing code

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
harbor-client/src/lib.rs	Adds new MintConnectionInfo enum with FromStr implementation
harbor-ui/src/main.rs	Updates message types and removes error handling for invalid strings
harbor-ui/src/routes/mints.rs	Updates button handlers to use conditional enabling based on parsed input

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The parsing order in FromStr implementation could be ambiguous if both MintUrl and InviteCode can successfully parse the same string. Consider documenting the precedence order or adding validation to ensure mutual exclusivity.

Suggested change

	impl FromStr for MintConnectionInfo {
	type Err = anyhow::Error;
	fn from_str(s: &str) -> Result<Self, Self::Err> {
	if let Ok(url) = MintUrl::from_str(s) {
	Ok(Self::Cashu(url))
	} else if let Ok(invite_code) = InviteCode::from_str(s) {
	Ok(Self::Fedimint(invite_code))
	} else {
	Err(anyhow::anyhow!("Invalid mint connection info: {}", s))
	/// Attempts to parse a string as either a Cashu MintUrl or a Fedimint InviteCode.
	/// Precedence: MintUrl is tried first, then InviteCode.
	/// If a string can be parsed as both, an error is returned to avoid ambiguity.
	impl FromStr for MintConnectionInfo {
	type Err = anyhow::Error;
	fn from_str(s: &str) -> Result<Self, Self::Err> {
	let mint_url_result = MintUrl::from_str(s);
	let invite_code_result = InviteCode::from_str(s);
	match (mint_url_result, invite_code_result) {
	(Ok(_), Ok(_)) => Err(anyhow::anyhow!(
	"Ambiguous input: can be parsed as both MintUrl and InviteCode: {}",
	s
	)),
	(Ok(url), Err(_)) => Ok(Self::Cashu(url)),
	(Err(_), Ok(invite_code)) => Ok(Self::Fedimint(invite_code)),
	(Err(_), Err(_)) => Err(anyhow::anyhow!("Invalid mint connection info: {}", s)),