Stop reporting include_attachments_context as an available feature

What does this MR do and why?

Resolvers::Ai::UserAvailableFeaturesResolver maps every category in Ai::AdditionalContext::DUO_CHAT_CONTEXT_CATEGORIES to an include_<category>_context unit primitive name and reports the ones the user may use. The attachments category deliberately has no unit primitive, because it carries the image bytes the user attached to one message rather than a context source the user opts into. This MR stops the resolver from deriving a name for it.

The merged MR listed attachments as "already enabled", on the assumption that allowed_to_use? would filter the unknown name out because the cloud connector does not define it. That only holds while Amazon Q is disconnected. check_amazon_q_feature returns an allowed response for :chat before the unit primitive is validated, and :chat is in AMAZON_Q_FEATURES, so with Amazon Q connected the resolver reported include_attachments_context to clients as a real capability. Nothing consumes that name today, so there is no user-visible breakage — it was advertising a capability that does not exist. The fix drops the category before the name is built: the resolver subtracts DUO_CHAT_CONTEXT_CATEGORIES_WITHOUT_UNIT_PRIMITIVE from DUO_CHAT_CONTEXT_CATEGORIES.values, rather than marking the category enabled. That list is defined in ee/lib/ai/additional_context.rb immediately below DUO_CHAT_CONTEXT_CATEGORIES and derived from it, because whether a category has a unit primitive is a property of the category rather than of the resolver. A spec asserts the name is never reported and fails without the change.

Documentation. The comment above DUO_CHAT_CONTEXT_CATEGORIES said every new category needs a unit primitive, which contradicted the attachments entry directly below it. It now says a unit primitive is required except for the categories listed in DUO_CHAT_CONTEXT_CATEGORIES_WITHOUT_UNIT_PRIMITIVE just below the hash. The Amazon Q reasoning, why the category is dropped up front rather than left to allowed_to_use?, lives in the resolver instead, since it describes the resolver rather than the category. The comment also records a side effect worth knowing: registering a category widens the write paths as well as the read path, because the REST allowlist in ee/lib/api/chat.rb and AiAdditionalContextInput for the aiAction mutation both start accepting it, for classic Duo Chat too. That side effect is unchanged here and is documented rather than altered; restricting classic chat's acceptance of the category would be a separate decision.

How to validate

bundle exec rspec ee/spec/graphql/resolvers/ai/user_available_features_resolver_spec.rb ee/spec/graphql/types/ai/additional_context_category_enum_spec.rb

9 examples pass. The regression test can be confirmed by removing the subtraction from the resolver, after which the example does not report a category without a unit primitive, even when allowed_to_use? is permissive fails.

References

• Follow-up to: !250665 (merged)

The three points addressed here were raised in review of that MR: the resolver reporting a unit primitive for attachments, the comment above DUO_CHAT_CONTEXT_CATEGORIES contradicting the entry below it, and the write-path side effect of registering a category.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.