91: Reconcile timed-out Evelyn IOU burner swaps in later iterations

openspec/specs/jupiter-swap-service/spec.md

@@ -102,7 +102,7 @@ The service SHALL first accept a Jupiter execution response only when it has sta
 
 #### Scenario: Provider succeeds but confirmation times out
 - **WHEN** a fully validated Jupiter execution response contains a signature whose independent `CONFIRMED` outcome is `TIMED_OUT`
-- **THEN** the service throws a structured checked outcome exception preserving the signature, requested commitment, and unknown outcome warning and does not automatically resubmit an equivalent transaction
+- **THEN** the service throws a structured checked outcome exception preserving the signature, requested commitment, original validity metadata and unknown outcome warning and does not automatically resubmit an equivalent transaction
 
 ### Requirement: Swap confirmation timeout policy
 The reference service SHALL accept a constructor-injected, non-null, strictly positive confirmation timeout and SHALL preserve its existing constructor with a two-minute default. The configured duration SHALL be passed unchanged to independent confirmation after submission and SHALL begin governing only when awaiting the known signature starts.
@@ -116,15 +116,15 @@ The reference service SHALL accept a constructor-injected, non-null, strictly po
 - **THEN** construction fails before any operation can be submitted
 
 ### Requirement: Post-submission communication and interruption policy
-If independent confirmation fails with an I/O error after the signature is known, the service SHALL throw an `IOException` whose message identifies the swap operation, includes the signature, and states that the on-chain outcome is unknown, with the original error retained as its cause. Interruption SHALL propagate directly as `InterruptedException` without another RPC or Jupiter request. Neither condition SHALL trigger rebuilding, re-signing, retrying, or resubmitting a transaction.
+If independent confirmation fails with an I/O error after the signature is known, the service SHALL throw a structured `IOException` preserving the original signature, original transaction-validity metadata, submission uncertainty and underlying cause. Interruption SHALL propagate as `InterruptedException` while preserving known signature/validity context in structured form without another RPC or Jupiter request. Neither condition SHALL trigger rebuilding, re-signing, retrying, or resubmitting a transaction.
 
 #### Scenario: Confirmation communication fails
 - **WHEN** independent confirmation throws an I/O error for a known submitted signature
-- **THEN** the service reports the signature and unknown on-chain outcome while preserving the original error and performs no retry or resubmission
+- **THEN** the service reports the structured signature, original validity metadata and unknown on-chain outcome while preserving the original error and performs no retry or resubmission
 
 #### Scenario: Confirmation is interrupted
 - **WHEN** independent confirmation throws `InterruptedException`
-- **THEN** that interruption propagates directly and the service performs no subsequent request
+- **THEN** that interruption retains its known signature and validity context, propagates normally and the service performs no subsequent request
 
 ### Requirement: API and implementation separation
 The stable service interface and result value SHALL reside in the Jupiter swap API package, while HTTP DTOs, endpoint handling, throttling, and the reference implementation SHALL remain in the reference-implementation package.
@@ -132,3 +132,26 @@ The stable service interface and result value SHALL reside in the Jupiter swap A
 #### Scenario: Downstream API consumer
 - **WHEN** downstream code depends only on the Jupiter swap API package
 - **THEN** it can invoke swaps and inspect results without depending on private wire DTOs or reference-implementation mechanics
+
+### Requirement: Submission certainty and original validity remain structured
+The integration SHALL expose submission certainty, known signature, original cause and original validity in structured form. Original validity SHALL retain the order height, actual blockhash, taker and finalized submission anchor. Signing SHALL preserve the hash and required taker signer. Expiry evidence SHALL be bound to a populated local first signature; contradictory provider identity SHALL require manual handling. Existing perps outcome construction SHALL remain compatible.
+
+#### Scenario: Preparation fails
+- **WHEN** mint/order acquisition, validation, signing or pre-submission validity preparation fails before execution submission
+- **THEN** the error is structured as pre-submission and no execution or automatic retry occurs
+
+#### Scenario: Execution response is lost
+- **WHEN** execution may have been submitted and no trustworthy signature is available
+- **THEN** the error remains structured as uncertain submission and does not authorize automatic recovery or resubmission
+
+#### Scenario: Provider identity contradicts the signed transaction
+- **WHEN** an execution response signature differs from the populated first signature of the signed payload
+- **THEN** the result is not treated as confirmed and uncertain submission requires manual reconciliation
+
+#### Scenario: Sponsor identity is completed by Jupiter
+- **WHEN** Jupiter supplies a valid provider signature while the local first signature is blank
+- **THEN** the signature can be awaited and reconciled by status, but original local validity cannot establish non-executed expiry
+
+#### Scenario: Timeout retains original validity
+- **WHEN** confirmation of a known submitted signature times out
+- **THEN** the exceptional outcome exposes its original validity data without substituting a new transaction or blockhash