Fix missing and malformed Sentry reports in Secrets Manager

Why this MR ?

• Fixes #624868 (closed), part of #611251
• Secrets Manager runtime errors either never reached Sentry or reached it malformed, so an OpenBao or CDot outage looked identical to a permissions problem in Sentry
• Two places also carried a user-chosen secret name: the warning handler's payload, into Sentry and application_json.log, and the GraphQL error handler's exception message, into Sentry and exceptions_json.log
• Sibling MR for the metrics half of the same parent issue, still open - !252512 (merged)
• This MR closes the reporting gaps 🙈

What does this MR do ?

• EffectiveCapabilitiesService swallowed every OpenBao error into an all-false capability map with no log line and no Sentry event - now reports it, return value unchanged
• An OpenBao 404 was reported to Sentry as an exception and shown to the user as Internal server error. - now treated as a missing resource: no Sentry event, GraphQL error becomes resource-not-available
• The GraphQL error handler reported the raw ApiError, and OpenBao names the requested path in its own error text (no handler for route "<path>". route entry not found.), so the secret name became the Sentry event title. It now reports a copy with quoted segments redacted - same class, same backtrace, and route entry not found still readable. Nothing downstream did this: Gitlab::Sanitizers::ExceptionMessage only rewrites URI errors
• handle_openbao_warnings! passed tags:/extra: as keyword args to a method that only takes positional args, so no Sentry tag was ever set - fixed, and the raw request path is replaced with Gitlab::Instrumentation::Openbao.operation_for; log field renamed endpoint -> operation, and message now uses ::Labkit::Fields::LOG_MESSAGE
• Deleted a feature_category: argument on the GraphQL error handler that could never have worked in any position
• Two silent rescues in the start-trial mutation now report to Sentry. The post-trial lookup also moves from Entitlement.for to Entitlement.for!, because for fails closed to :ineligible inside the resolver and the second rescue could never fire. Behaviour change: during a CDot outage the mutation now returns a null entitlement - which is what the field already documents - instead of :ineligible immediately after a successful trial start
• Entitlement resolution failures used log_exception, which never reaches Sentry - three sites switched to track_exception, which also logs. The CI job-request site stays log-only: the runner presenter re-resolves through the non-bang Entitlement.for later in the same request and reports there, so reporting here too would only duplicate it

References

• Issue - #624868 (closed)
• Parent issue - #611251
• Sibling MR, metrics half, open - !252512 (merged)
• Overlapping open MR - !251010 (merged)