Clarify Provider navigation state after Save or endpoint errors #83

Summary

After editing an existing Provider, an error from Save or the endpoint/configuration flow leaves the navigation guard in a generic dirty/pending state. Selecting another Provider then opens the same "Save provider changes?" dialog again, without distinguishing whether:

• provider persistence failed;
• persistence succeeded but catalog generation / Gateway refresh failed; or
• only an endpoint test failed while the draft remains unsaved.

This makes the user repeat a Save action that may already have persisted, or see the same failure again without actionable context.

Reproduction

Observed in the portable build from commit 7257701bf4c5d8be6fd3f49da0b0d86690dc4180.

1. Open an existing third-party Provider.
2. Change a configuration field.
3. Trigger the Save/test path and receive an error.
4. Select another Provider.
5. The generic unsaved-changes dialog opens and offers Save again.

Current implementation evidence

• saveProviders persists with api.saveProviders(next) before catalog generation and Gateway refresh.
• Later failures are rethrown as if the entire save failed.
• savePendingProviderNavigation catches the failure without transitioning or classifying pending/dirty state.
• The navigation guard therefore cannot tell a persistence failure from a post-save refresh failure.

A deterministic state replay leaves both dirty=true and pending!=null after the failed save branch.

Expected behavior

• Never silently discard a draft after a true persistence failure.
• Distinguish provider persistence from post-save catalog/client/Gateway refresh.
• If provider persistence succeeded, refresh the baseline and do not ask the user to save the same Provider data again; report the follow-up failure separately.
• If persistence failed, keep the draft but show the failure in the navigation dialog (or an adjacent persistent error) with clear Retry, Discard, and Cancel behavior.
• A failed endpoint test must not itself create additional dirty state beyond actual draft changes.

Acceptance criteria

• Save outcome tracks provider persistence separately from follow-up regeneration/sync/refresh.
• A persisted Provider draft is not presented as unsaved when only a follow-up operation failed.
• A true persistence failure preserves the draft and presents an actionable error without ambiguous repeated prompts.
• Switching Providers after each failure class follows the expected navigation behavior.
• UI tests cover persistence failure, post-save failure, and endpoint-test failure.