fix: map empty bedrock settings strings to null

[ethanndickson]

Problem

Dogfood CI failed applying module.ai.coderd_ai_provider.agents_bedrock:

Error: Provider produced inconsistent result after apply
... unexpected new value: .settings: inconsistent values for sensitive attribute.

The failing row is a legacy agents-bedrock provider whose stored settings blob is empty — a shape current Coder can no longer produce (you can't get a provider into this state anymore), which is why prior testing never hit it. Dogfood adopts this pre-existing row via an import block while the config declares only settings.bedrock.region = "us-east-2".

Walking the flow:

1. Import/Read produced settings = null. The empty stored blob makes the server return settings: null, so provider.Settings.Bedrock == nil and stateFromProvider's if provider.Settings.Bedrock != nil branch is skipped entirely — the block is stored as null, and no "" is ever written.
2. The plan for model/small_fast_model became known null. They are Optional+Computed, so they are first marked unknown, then UseStateForUnknown copies the imported prior-state known-null back (it only short-circuits when the entire prior state is null, i.e. a fresh create — not after an import).
3. The in-place Update got "". Because the config now sets region, the PATCH sends a real bedrock object with model serialized as "". The server echoes Bedrock != nil with model: "", so stateFromProvider enters the branch and (pre-fix) wrote types.StringValue("").
4. Mismatch. Plan model = known null; applied model = "". Terraform requires final state to equal every known planned value, and null != "". Since settings.bedrock contains sensitive write-only leaves, core masks the offending leaf as the opaque .settings: inconsistent values for sensitive attribute.

Fix

Map the server's empty bedrock strings (region, model, small_fast_model, role_arn) back to null via stringValueOrNull in stateFromProvider, so absence has a single representation (role_arn already did this). This makes the Update-path echo of "" match the known-null plan.

Coder drops empty optional strings on the wire (omitempty), so a configured "" reads back as null and would reproduce the same inconsistency. Reject that up front with stringvalidator.LengthAtLeast(1) on the four optional bedrock strings, turning an opaque apply-time failure into a clear validation error — omit the attribute instead of setting it empty.

Notes

Added a pure-function regression test (TestAIProviderStateFromProviderMapsEmptyBedrockStringsToNull) that fails pre-fix and passes post-fix without any mock server or Terraform, plus two schema-validation cases for the empty-string rejection. Documented the null-vs-"" state-mapping footgun in AGENTS.md.

[ethanndickson]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. What shall we delve into next?

Reviewed commit: c95329463b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".