fix: report server capabilities in OpAMP responses

[michel-laterman]

What is the problem this PR solves?

The OpAMP spec requires the server to report its capabilities bitmask in the first ServerToAgent response. Fleet-server was not setting this field, so agents could not discover what the server supports.

How does this PR solve the problem?

Send the serverCapabilities bitmask (AcceptsStatus, AcceptsEffectiveConfig) in the ServerToAgent response when an agent enrolls or reconnects from a non-active status (offline, disconnected). Active agents (online, error, degraded) do not receive capabilities on every message to reduce response size. An isActiveStatus helper determines which statuses are considered active.

Design Checklist

• I have ensured my design is stateless and will work when multiple fleet-server instances are behind a load balancer.
• I have or intend to scale test my changes, ensuring it will work reliably with 100K+ agents connected.
• I have included fail safe mechanisms to limit the load on fleet-server: rate limiting, circuit breakers, caching, load shedding, etc.

Checklist

• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool

Related issues

• Closes [OpAMP] fleet-server should send capabilites #6785

[mergify]

This pull request does not have a backport label. Could you fix it @michel-laterman? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-./d./d is the label to automatically backport to the 8./d branch. /d is the digit
• backport-active-all is the label that automatically backports to all active branches.
• backport-active-8 is the label that automatically backports to all active minor branches for the 8 major.
• backport-active-9 is the label that automatically backports to all active minor branches for the 9 major.