Re-enabling a disabled entry on an armed plan skips the arming grant #1777

Problem

On an armed plan (enabled, auto_purchase, with a cap), a PUT /api/plans/{id} can turn a disabled services entry back on without the execute:purchases arming-grant check.

• The PUT re-enables the entry. mergeRequestedServices overlays the request onto the stored entry it names (internal/api/plan_services_merge.go). overlayServiceConfig sets stored.Enabled = req.Enabled, and buildServiceConfig always builds the request entry with Enabled: true (internal/api/types.go). So a PUT naming a disabled entry re-enables it.
• The arming gate doesn't see it. planArmEscalates (internal/api/auto_purchase_grant.go) compares DerivePlanProviders and DerivePlanServices, which ignore Enabled. A re-enabled entry therefore isn't an escalation, updatePlanGated writes it through the ungated UpdatePurchasePlan, and the armed plan starts buying for that entry again with no grant check.

How likely it is

Rare. No current API write disables a single entry: the flat form always sends Enabled: true, and PATCH only toggles plan-level fields. So it needs an entry that is already disabled, from legacy data or a migration. It predates the bound-plan work.

Scope note

For bound plans (#1746), slice A step A5 already counts a re-enabled group as an escalation. This issue covers only plans without the bound_groups marker. Raised by CodeRabbit on #1774, and left out of that PR on purpose.

Possible fix

In planArmEscalates, or in the updatePlanGated routing, treat "an entry goes from disabled to enabled on a plan that stays armed" as an escalation.

That changes behaviour for existing plans. Admin-key callers, whose arming the gate refuses outright, would get a 403 for such a re-enable. Needs a decision before implementing.