Allow enabling/disabling software inventory per-fleet via the API

[noahtalerman]

Goal

User story
As a Fleet user,
I want the stable API to support enabling/disabling software inventory per-fleet
so that I can enable/disable software inventory via the API without risking my automations breaking.

Changes

Product

• UI changes: No changes
• CLI (fleetctl) usage changes: No changes
• YAML changes: No changes
• REST API changes: Draft PR
• Fleet's agent (fleetd) changes: No changes
• Fleet server configuration changes: No changes
• Exposed, public API endpoint changes: No changes
• fleetdm.com changes: No changes
• GitOps mode UI changes: No changes
• GitOps generation changes: No changes
• Activity changes: No changes
• Permissions changes: No changes
• Changes to paid features or tiers: No changes
• My device and fleetdm.com/better changes: No changes
• Usage statistics: No changes
• Other reference documentation changes: No changes
• First draft of test plan added
• Once shipped, requester has been notified
• Once shipped, dogfooding issue has been filed

Engineering

Scope decisions (Slack thread):

• API addition only: accept features.enable_software_inventory on PATCH /api/v1/fleet/fleets/{id} with PATCH-merge semantics (omitted key keeps the stored value), following the features.historical_data pattern (TeamPayloadFeatures in server/fleet/teams.go + apply block in ee/server/service/teams.go ModifyTeam).

• Same effect as the existing GitOps path: no gating of software functionality and no cleanup of already-collected software when inventory is disabled.

• No new activity for this field.

• POST /fleets and PATCH /fleets/0 (Unassigned) keep ignoring features (pre-existing behavior, consistent with historical_data); Unassigned hosts follow the global config setting.

• Test plan is finalized

• Contributor API changes: No changes

• Feature guide changes: No changes

• Database schema migrations: No changes (fleet features live in the teams.config JSON column and already round-trip via GitOps)

• This is a premium only feature: Yes (fleets endpoints are Premium-only; the global features.enable_software_inventory setting remains available in Fleet Free)

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

Risk assessment

• Risk level: Low

Test plan

Make sure to go through the list and consider all events that might be related to this story, so we catch edge cases earlier.

Core flow

• Disable software inventory for a fleet via PATCH /api/v1/fleet/fleets/{id} with {"features": {"enable_software_inventory": false}} and verify the fleet's hosts stop receiving software_* detail queries on next check-in. Already-collected software remains visible until it goes stale — expected; matches existing GitOps behavior.
• Re-enable via the same endpoint and verify software queries resume and inventory refreshes.
• Modify other fleet settings (e.g. name, features.historical_data) without the enable_software_inventory key and verify the setting is unchanged (PATCH-merge semantics).
• With global features.enable_software_inventory disabled, enable it on a fleet and verify that fleet's hosts still report software (fleet setting overrides global for the fleet's hosts).

API

• Test all API endpoints added or modified in the API changes section of this issue
• Verify any new API endpoints appear in the list when adding an API-only user. The API endpoints display name, method, and path is the same as listed in the API reference docs
• Verify error handling for invalid inputs where applicable

Permissions

• Verify role restrictions are applied correctly for global roles
• Verify role restrictions are applied correctly for fleet-level roles

Edge cases

• Invalid value (e.g. {"features": {"enable_software_inventory": "yes"}}) returns a 4xx error and does not change the setting.
• PATCH /api/v1/fleet/fleets/0 (Unassigned) ignores features (pre-existing behavior, consistent with historical_data); Unassigned hosts follow the global config setting.
• POST /api/v1/fleet/fleets ignores features in the payload; new fleets snapshot the global features (pre-existing behavior).
• Toggling via fleetctl gitops after toggling via the API round-trips correctly: fleetctl generate-gitops reflects the API-set value.

Supplemental testing

Testing notes

Confirmation

1. Engineer: Added comment to user story confirming successful completion of test plan (include any special setup, test data, or configuration used during development/testing if applicable).
2. QA: Added comment to user story confirming successful completion of test plan.
3. QA: Determined whether this story needs Playwright automation.
   • Needs automation: Yes / No
   • If yes, filed a follow-up issue in the :help-qa project with status "Needs automation": TODO