feat(cluster_agents): add IsReceptive to the Agent struct

What does this MR do?

GitLab sends is_receptive on the cluster agent entity, but the Agent struct in cluster_agents.go does not carry it, so the value is dropped on decode. This adds it as IsReceptive bool with the is_receptive JSON tag.

The field is exposed on line 11 of ee/lib/ee/api/entities/clusters/agent.rb, which is prepended into API::Entities::Clusters::Agent by the prepend_mod call on line 17 of lib/api/entities/clusters/agent.rb. The exposure carries no condition: no if:, no unless: and no feature check, so every response rendered with that entity carries the key. Three endpoints render with it, in lib/api/clusters/agents.rb: list on line 32, get on line 48 and register on line 69. Because the exposure comes from the EE code path, a CE instance omits the key and the field stays false, which is why a plain bool rather than a pointer matches the guidance in the contributor guide.

Documentation: https://docs.gitlab.com/api/cluster_agents/

One thing worth flagging: the response examples on that page do not yet show is_receptive, although the same page documents receptive agents as a feature. I confirmed the field against a booted gitlab/gitlab-ee:latest image (GitLab 19.3.1-ee) by asking the loaded Rails application what the Grape entity exposes, rather than trusting the examples on the page.

I did not touch RegisterAgentOptions. The register endpoint declares only name (line 57 of the same routes file) and the documented attribute table for it lists only id and name, so there is no request parameter to add here.

I found this while building gitlab-mcp-server, an MCP server that exposes GitLab through this SDK.

Is this a breaking change?

No. This adds one field to a response struct, so every existing caller still compiles and behaves exactly as before. On a CE instance the key is absent and the field decodes to its zero value, which is the same answer a caller gets today.

How was this tested?

TestListClusterAgents, TestGetClusterAgent and TestRegisterClusterAgent now carry the key in their fixtures and assert it: true for the get and register agents and for the first agent in the list, false for the second, so both states are covered. I checked the assertions are load-bearing by changing the JSON tag to a name GitLab does not send, watching all three tests fail on IsReceptive, and then restoring it.

Related to #2300