Software installs aren't orphaned when an installer is deleted

[cdcme]

Goal

User story
As a Fleet operator running software automation at scale,
I want the install queue to reject any queued or in-flight activity whose installer no longer exists,
so that installs don't silently fail.

Background

From the customer-numa post-mortem in April 2026.

When an installer is deleted while an install is queued or in flight, the queue can keep a row whose installer no longer exists, and orbit can't resolve it. #44284 and c2eb45f9a7 limited the damage, but this is still possible from other delete paths. This story aims to make it impossible. It depends on #25912, which adds the cancellation step the new behavior needs.

Changes

Product

• UI changes: No changes
• CLI (fleetctl) usage changes: No changes
• YAML changes: No changes
• REST API changes: No changes
• 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

• Test plan is finalized
• Contributor API changes: No changes
• Feature guide changes: No changes
• Database schema migrations: Change the in-flight activity foreign key so an installer can't be deleted while an install still references it.
• Load testing: Not required
• This is a premium only feature: No

Risk assessment

• Requires testing in a hosted environment: Yes
• Requires load testing: No
• Risk level: Low
• Risk description: The foreign key change alters delete behavior. Cancel pending installs/uninstalls & revoke licenses when editing and deleting App Store (VPP) apps #25912 cancels in-flight installs before delete, so deletes still succeed.

Test plan

Core flow

• Delete an installer that has a queued install and an in-flight install. The installs cancel first and the delete succeeds. No orphaned queue row remains, and orbit logs no "installer details not found" loop.

Edge cases

• Upgrade from a version before this change that already has orphaned rows. Each one resolves to a failed state.
• A delete path that doesn't cancel first. The delete is blocked with a clear error instead of stranding the row.