Define atomic provider endpoint and credential updates

What problem would this solve?

A provider configuration save can update routing fields and credentials through separate persistence operations. Concurrent saves or provider construction during a save need a defined consistency contract so a provider uses an endpoint and credential from the same accepted configuration.

What would a good outcome look like?

Choose an atomic-publication scope for built-in provider settings and custom-provider documents: should every provider constructor see a complete old or complete new endpoint/credential pair, including across multiple Goose processes, and what happens if either backing store fails?

Possible approaches

Coordinate readers and writers around versioned configuration snapshots, or another transaction mechanism that includes secret storage and rollback. Serializing only ACP save handlers does not cover constructors, other writers, or separate processes. Preserve environment-variable precedence, keyring/file-backed storage, existing provider identities, and unchanged credentials where no routing change occurs.

Additional context

Acceptance should cover two valid concurrent paired saves, construction overlapping a save, secret/config persistence failures, existing credential-source precedence, and the chosen process boundary. Define routing-field changes that require explicit replacement credentials separately from concurrency guarantees.

• I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches Ready on the Goose Issues board.