Add supertest coverage asserting `POST /:id/execute` and `/:id/cancel` return `409 INVALID_STATE` with the correct JSON envelope for already-executed/cancelled settlements

[Jagadeeshftw]

📌 Description

SettlementService's private requirePending throws ApiError.conflict(..., "INVALID_STATE") when a caller tries to execute or cancel a settlement that isn't pending. Unit tests for settlementService.ts likely already cover this at the service level, but there doesn't appear to be a full HTTP-level test (via routes/settlements.ts + errorHandler) proving the same is true through the actual POST /:id/execute//:id/cancel routes with the exact 409 status and JSON shape a client would see.

🧩 Requirements and context

• Add a supertest-based test that opens a settlement, executes it, then attempts to execute it again and asserts 409 with { error: { code: "INVALID_STATE", ... } }.
• Add the equivalent test for cancel-after-execute and cancel-after-cancel.
• Assert the response body shape matches exactly what errorHandler.ts produces for ApiError instances.

🛠️ Suggested execution

• Extend src/routes/settlements.test.ts with the full open -> execute -> re-execute / re-cancel sequences via supertest against createApp().

✅ Acceptance criteria

• New tests cover execute-after-execute, cancel-after-execute, and cancel-after-cancel, all asserting 409 and the INVALID_STATE code at the full HTTP layer.
• Existing settlements.test.ts suite is unaffected.

🔒 Security notes

N/A — test-only; verifies settlement state-machine invariants are enforced end-to-end, preventing double-execution/double-cancellation of the same settlement.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours