Reaped and swept purchases send a 'retry manually' email although the commitment may already exist #1415

What happens

Since #1245 (fix for #1195), every writer that ends a purchase execution row failed logs the purchase_execution_failed marker and sends the purchase-failed email. That includes two sweeps:

• the stuck-row reaper (reapOne in internal/purchase/reaper.go), which fails approved/running rows that sat too long, and
• the stranded-approval sweep (safeFail in internal/purchase/manager.go, and failClaimedRedrive in internal/purchase/stranded_redrive.go, which fails a claimed row the same way).

For those rows they all send the same generic template (purchaseFailedTemplate in internal/email/templates.go):

Some purchases could not be completed. Please review and retry manually.

It lists every selected recommendation not flagged Purchased as a "Failed Purchase". For a reaped or swept row those flags were usually never saved, so in practice every selected recommendation shows up.

Why it's risky

The sweeps fail these rows because the purchase run was interrupted, not because the provider refused it. The commitment may already exist: the executor could have bought and then died before it saved the result. The row's Error text says so ("Verify on the cloud provider that no commitment was created..."). The email instead tells the operator to retry by hand and calls every item a failed purchase. An operator who follows it could buy the same commitment twice. Some recommendation types (for example Azure savings plans) have no provider-side idempotency key that would block a duplicate.

Expected

Reaped and swept rows still raise the marker/alarm #1245 added. Their email is a distinct "outcome unknown" message that:

• tells the operator to check the cloud console before buying again,
• names only the affected execution and the recommendations whose outcome is unknown, and
• never says "retry".

Rows that really failed (executor errors, cap or authorization refusals, plan-step failures) keep today's email.

Origin

Regression from #1245 (merged 2026-10-25), which closed #1195. That PR's own review notes flagged that the generic template does not match reaped and safeFail rows.