Feature: Support configurable Bedrock Guardrails on model invocations

[jmino]

Summary

Add optional Bedrock Guardrails support so deployers can attach content safety filtering and monitoring to all model invocations without modifying inference-api code.

Problem

Institutions deploying this stack in higher education have duty-of-care obligations that require proactive monitoring for harmful content (self-harm, crisis language, dangerous behaviors). Currently there is no way to attach a Bedrock Guardrail without modifying the inference-api source. Claude's built-in safety layer is reactive (responds to the user) but does not alert staff.

Proposed Solution

Add optional CDK_GUARDRAIL_ID and CDK_GUARDRAIL_VERSION environment variables. When set, the inference-api passes them to the Strands BedrockModel constructor which already supports guardrail_id, guardrail_version, guardrail_stream_processing_mode, and guardrail_trace. When unset, behavior is unchanged.

Why this belongs upstream

• Strands SDK already supports it; this is config wiring, not new capability
• Common compliance requirement (FERPA duty-of-care, institutional safety policies)
• Zero-cost when disabled (environment variables unset = no change)
• Aligns with existing optional-feature pattern (CDK_ARTIFACTS_ENABLED, CDK_MCP_SANDBOX_ENABLED, CDK_FINE_TUNING_ENABLED)

Suggested implementation

1. Add CDK_GUARDRAIL_ID and CDK_GUARDRAIL_VERSION to config.ts (optional, no validation when unset)
2. Thread through InferenceApiStack as ECS task environment variables
3. In model instantiation, pass to BedrockModel when present
4. Handle guardrail-blocked responses gracefully in the stream (user sees a friendly message, not a raw error)

Acceptance criteria

• CDK_GUARDRAIL_ID + CDK_GUARDRAIL_VERSION environment variables wired to BedrockModel
• Guardrail-blocked responses surface as a user-friendly message in chat
• No behavioral change when environment variables are unset
• Documentation updated in deployment guide