refactor(coderd): store bedrock model resolution in provider settings - #29175

Follow-up to #29112, which stores the resolved Bedrock model in its own table. Keyed by inference profile ARN, that table needed a migration, three queries, dbauthz wrappers, a store-interface method, and a join in the provider payload. This PR keeps the values in the settings blob instead, where the rest of the provider's Bedrock configuration already lives.

The plumbing that disappears is the point: aibridgedserver no longer collects identifiers, queries mappings, or threads a map through aiProviderToProto; it reads two fields off the settings it already decoded. Net 314 deletions against 119 insertions, and no schema change.

Resolution still runs after the write commits, so no AWS call happens inside a transaction, and still runs on every save. Storing the result now means a second UpdateAIProvider with the resolved settings, which is the one thing the table did not need.

Server ownership is enforced by clearing rather than validating. The write path zeroes resolved_model and resolved_small_fast_model before storing and rewrites them after resolution, so a client-supplied value is discarded rather than rejected, and a stale value cannot survive a settings change. That is one two-line helper instead of the validation, merge carry-forward, and compare-before-write that an earlier attempt at this needed.

What is lost relative to the table: two providers configured with the same ARN each store their own copy, and each resolves it separately. Resolution already ran per save, so this costs storage rather than AWS calls.

Behavior is unchanged. An unresolved ARN still serves as its own identity, a failed lookup still reports 400 while leaving the provider stored, and the gateway still never calls the Bedrock control plane.

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

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