Features blocked by a missing permission answer inconsistently, and tell the operator nothing

[JGoutin]

When a deployment lacks an IAM permission or a resource a feature needs, the gateway
answers in at least six different ways. That is a problem for both audiences at once: the
caller is blamed for the operator's configuration, and the operator gets no signal at all.

Observed, across released and unreleased paths:

• The Conversations API, vector stores and batches answer a bare 403 Forbidden when the
  IAM permission is missing, with nothing in the log.
• iam:PassRole on the batch service role and the S3 Vectors actions are new permissions
  a deployment can be missing entirely, and both surface as a raw error.
• A batch job that fails because the service role cannot read the input returns a failed
  job with the explanation discarded — Bedrock says why, and the gateway drops it.
• Background indexing errors are written into a logging context that is not installed, so
  they are lost outright.
• The realtime WebSocket has no catch-all, and a WebSocket route does not pass through the
  error middleware, so an unexpected failure escapes unlogged.
• A missing web search permission produces no error at all: the model simply answers
  without searching.
• Where the pattern is handled, it is five hand-copied instances of the same two lines.

Expected, everywhere:

• To the caller: a generic 503 — the feature is not available on this deployment,
  contact the administrator. Identical whatever is missing, because the difference between
  "no permission" and "not configured" is a map of the backend.
• To the operator, at WARNING in the server log: exactly what is missing, by name.

Fix: one shared helper, used by every path, replacing the five copies rather than becoming
a sixth.