[backport camel-4.18.x] CAMEL-23461: camel-aws-bedrock - applyGuardrail reads guardrail identifier from wrong header

[oscerd]

Backport of #23151

Cherry-pick of #23151 onto camel-4.18.x.

Original PR: #23151 - CAMEL-23461: camel-aws-bedrock - applyGuardrail reads guardrail identifier from wrong header
Original author: @oscerd
Target branch: camel-4.18.x

Backport notes

• The upgrade-guide entry was redirected from camel-4x-upgrade-guide-4_21.adoc (only on main) to camel-4x-upgrade-guide-4_18.adoc under the Upgrading from 4.18.2 to 4.18.3 section.
• mockito-junit-jupiter was added as a test-scoped dependency on camel-aws-bedrock because the module did not already declare it on 4.18.x (other AWS components like camel-aws2-sns/-sqs/-athena already use the same ${mockito-version} from the parent pom).
• Per project convention, the matching camel-4x-upgrade-guide-4_18.adoc entry will be added to main in a follow-up doc-sync PR so the main upgrade-guide history stays consistent with what ships on 4.18.x.

Original description

The applyGuardrail producer operation was reading the guardrail identifier from CamelAwsBedrockGuardrailConfig as a String, but that header is documented as GuardrailConfiguration and is consumed as such by converse / converseStream. Routes mixing the two operations silently produced a null identifier and fell back to the endpoint configuration only.

A dedicated CamelAwsBedrockGuardrailIdentifier header (BedrockConstants.GUARDRAIL_IDENTIFIER, typed String) is introduced for applyGuardrail. GUARDRAIL_CONFIG stays reserved for converse / converseStream.

Unit test added (mocked BedrockRuntimeClient, no AWS access required) covering endpoint fallback, the new header, the regression where GUARDRAIL_CONFIG must not corrupt the applyGuardrail request, and the missing-identifier failure path.

JIRA: https://issues.apache.org/jira/browse/CAMEL-23461

---

Claude Code on behalf of Andrea Cosentino.