Offer to init repo when adding existing repo fails (#1799)

[SaurabhCodesAI]

Description

When ExistingRepoWindow gets a "does not exist" or "is not a valid repository" error from borg, prompt the user to initialize a new repo at that location. If accepted, open AddRepoWindow pre filled with the URL and name from the original dialog. If declined, fall through to the normal error message.

Changes:

• ExistingRepoWindow: added init_requested signal and run_result() override that detects repo not found errors and shows a confirmation dialog
• RepoTab: connected init_requested, added _open_init_from_existing() which opens AddRepoWindow pre filled and sets local/remote mode correctly
• Tests: 5 parametrized cases covering both error strings, user accept/decline, unrelated errors, and pre-fill verification

Note: #1816 addresses the same issue but has been inactive since mid 2024. This is an independent implementation using a signal-based approach with test coverage.

Related Issue

Closes #1799

Motivation and Context

Users who try to add a non existent or uninitialized path via "Existing Repository" get a generic "Unable to add your repository" error with no guidance. This change detects that specific failure and offers to open the init dialog instead, reducing confusion between the two repo-adding workflows.

How Has This Been Tested?

• Manually tested on Ubuntu (WSL) with borg 1.2.8
• Tested both scenarios: path that doesn't exist, and path that exists but isn't a borg repo
• Both local paths and remote URLs handled correctly
• 5 unit tests added covering: both borg error strings (parametrized), user accepting init, user declining init, unrelated errors not triggering the prompt, and pre fill verification for local paths
• All existing unit tests pass alongside the 5 new ones (28 total)

Screenshots (if appropriate):

Types of changes

• Bug fix (non breaking change which fixes an issue)
• New feature (non breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have read the CONTRIBUTING guide.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

I provide my contribution under the terms of the license of this repository and I affirm the Developer Certificate of Origin.

[SaurabhCodesAI]

@m3nu can u review?

[m3nu]

If we add this, why not remove the distinction between new/existing repo?

[SaurabhCodesAI]

If we add this, why not remove the distinction between new/existing repo?

@m3nu
yeah sure good point, unifying them into one flow that auto detects would be cleaner...

[SaurabhCodesAI]

@m3nu please review?