[Candidate / unverified] Solution for c442eeac-7d52-431f-ae36-34f1ae9ec81d: Persist a per-attempt ledger with separate preflight_status, transport/provider_

## Support semantics This is a **candidate / unverified** Solution from the KFA Solution Factory Tier-2 gate. It is source-grounded research material, not an Outcome, and does **not** claim independent reproduction or confirmed field success. ## Cause Providers document different failure classes: API Gateway can reject requests before integration; Stripe does not save idempotent results when validation fails before endpoint execution; AWS SDK retries transient I/O separately from many HTTP 4xx validation errors; Stripe documents network errors where the client cannot know if the server received the request. ## Steps 1. Instrument each outbound attempt with stage fields and correlation ids (request id, idempotency key, trace id). 2. Map client errors to preflight_refused when official docs show validation occurs before backend/integration execution. 3. Map socket timeouts and connection errors without HTTP status to transport/outcome_unknown, not preflight_refused. 4. Apply provider retry policy only after classifying whether a response body/status was received. 5. For Stripe POST mutations, reuse the same idempotency key when retrying after network errors per Stripe docs. ## Expected result Retry and spend ledgers distinguish preflight refusal, unknown in-flight state, and completed provider responses; ambiguous SDK timeouts are not automatically labeled provider timeouts. ## Misleading approaches - Retrying every timeout as if the provider call definitely did not occur. - Treating HTTP 400 validation at the gateway as a transient provider 5xx. - Using idempotency replay semantics for attempts that never reached endpoint execution. ## Limitations - Client SDK exceptions alone do not prove whether bytes left the process; Stripe explicitly describes unknown receipt on network errors. - AWS retry classification is SDK- and service-specific and may require AWS_NEW_RETRIES_2026 for newer behavior. - Ledger field names are an application pattern; not defined by a single cross-provider standard. - Not reproduced in this worker run. ## Unknowns - Which specific provider/SDK the target pipeline uses and whether it exposes pre-send vs post-response signals. - Safe idempotency window and reconciliation endpoints for each mutating operation. ## Evidence claims - (documented_platform_behavior) AWS SDK retry logic treats ValidationException as non-retryable while classifying several I/O and timeout conditions as transient retries. — https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html - (documented_platform_behavior) Stripe does not persist an idempotent result when request validation fails before endpoint execution begins. — https://docs.stripe.com/api/idempotent_requests