refactor(coderd): resolve bedrock profiles before the provider write - #29179

Follow-up to #29112, which writes the provider first and stores the resolution in a second update. That leaves a window where a provider exists with an unresolved profile ARN, which then has to be explained everywhere: the gateway serves the ARN as its own identity, the audit entry records a pre-resolution row, and the publish is skipped so the provider only reaches the gateways after a restart.

Resolving before the write removes the state instead of describing it. A failed lookup now rejects the save and stores nothing, on create and on update alike.

Create resolves its own request, since a create carries the complete configuration. Update cannot: a PATCH supplies the model identifiers but inherits credentials and the external ID from the stored row, so the config to resolve is stored + patch. That merge now lives in lookupAndMergeSettings and is called twice, once before the transaction to resolve against and once inside it against the row being written. The two cannot disagree on the model identifiers, because both take them from the patch, so no reconciliation or conflict handling is needed.

The server-owned STS external ID is still generated inside the transaction, as before. A value generated for the preview would be one the operator's role trust policy could not reference yet either way, so resolution assumes the role with the stored value.

Net effect against the base branch: the second UpdateAIProvider is gone, clearBedrockModelResolution is gone (the resolution result is always assigned, which discards anything a client sent), and the update transaction is shorter than before this PR series started.

Relates to https://linear.app/codercom/issue/AIGOV-488

Created by Coder Agents on behalf of @evgeniy-scherbina.