test(purchase): regression guard for parallel multi-account execution isolation

[cristim]

Gap

The purchase-plan execution layer (internal/purchase/execution.go) runs each account's plan in parallel and tags execution records with cloud_account_id. Spec acceptance criterion E-2 requires that one account's failure must not fail others: if account A's credentials are invalid and account B's are valid, B's execution must complete successfully and A's must be marked failed in isolation.

The code path appears to support this (errgroup-style parallelism + per-account error capture), but it isn't covered by an automated test. Without one, an inadvertent refactor that swaps the errgroup for a serial loop, or that propagates an account-level error up the group, would silently regress the spec's central fault-tolerance promise.

Spec section: specs/multi-account-execution/acceptance.md E-2.

Acceptance criteria

Add an integration test in internal/purchase/execution_test.go (or a dedicated execution_multi_account_test.go) that:

• Creates a purchase plan targeting two AWS accounts via plan_accounts: account-V with valid mock credentials, account-I with invalid mock credentials.
• Executes the plan once.
• Asserts two purchase_executions rows are written, one per account.
  • account-V's row: status=success, cloud_account_id set to V's ID, result_data non-empty.
  • account-I's row: status=failed, cloud_account_id set to I's ID, error message present, the error message does NOT contain credential material (regression guard for log-sanitisation).
• Assert the two rows' result_data are independent (e.g., V's confirmation IDs are not present anywhere on I's row).
• Assert the timestamps prove parallelism: abs(V.completed_at - I.completed_at) < 2s AND max(V.completed_at, I.completed_at) - min(V.started_at, I.started_at) < (V_duration + I_duration). (The exact bound depends on the mock latencies; pick a sentinel that fails on a serial loop but passes on errgroup.)

Out of scope

• Load testing of CUDLY_MAX_ACCOUNT_PARALLELISM (separate ticket if needed).
• Credential refresh failures mid-execution.
• Mocking the actual AWS purchase APIs end-to-end — use the existing mock provider patterns (see internal/purchase/execution_test.go setup).

References

• Spec: specs/multi-account-execution/acceptance.md scenario E-2
• Execution layer: internal/purchase/execution.go
• Existing tests (extend, don't duplicate): internal/purchase/execution_test.go
• Schema: internal/database/postgres/migrations/000011_cloud_accounts.up.sql:131-135 (purchase_executions.cloud_account_id)
• Surfaced via the gap analysis on PR docs(specs): multi-account execution draft spec #89.

[cristim]

Closed since we now have those tests.