[woahwhattheheck]

Summary

Closes #507.

Settlement context (ON_TIME / AFTER_EXPIRY / AFTER_CANCEL) is decided only from Horizon transaction close time versus stored expiresAt / cancelledAt. Verify, monitor, receipt, timeline, and PDF share one classifier and warning vocabulary in shared/settlement.ts. Existing policy markdown (docs/LATE_PAYMENT_POLICY.md, docs/EXPIRY-AND-LATE-PAYMENT.md) stays the written spec.

Done when

• Payment whose close_time is after expiry settles with AFTER_EXPIRY, not wall clock
• Missing close_time does not mark PAID (503 TRANSACTION_CLOSE_TIME_UNAVAILABLE)
• Timeline and PDF/receipt show the same warning code (and shared copy) as the API
• No new overlapping policy doc

Changes

• Shared classifier (shared/settlement.ts): parse UTC close time, fail closed when missing, classify against expiry/cancel, export warning codes + API/receipt/timeline copy
• Backend domain re-exports the shared module (no parallel classifier)
• Monitor passes created_at into verification so close time is not dropped on the auto path
• Timeline keeps the expired milestone when settlement is AFTER_EXPIRY
• Receipt / PDF export read late-payment title/body from the shared definitions
• Tests: documented matrix (including clock-skew ON_TIME after EXPIRED sweep), shared-contract drift guard, handlers fixture for close_time + fail-closed 503, timeline AFTER_EXPIRY sequence

Test plan

• node --import tsx --test tests/invoice-settlement.test.ts tests/shared-settlement-contract.test.ts tests/invoice-cancel-payment-race.test.ts tests/memory-storage.test.ts tests/invoice-handlers.test.ts tests/invoice-service.test.ts (159 pass)
• npm run typecheck in backend and frontend
• node --test tests/invoice-workspace.test.js (13 pass, including AFTER_EXPIRY timeline)

Payout Routing

• EVM (Base/Arbitrum/Polygon/ETH): 0x18Dc2B9fc890a49e2a9cEBDb94e6c5A5cABa4F0a
• Stellar: GCUC7ECT3CP5OKA4N6C5LCOYZJKFUVKJT3RBS5JM3PJSG6VPRS5LYHL4

Original contribution and conditional reward claim

/claim #507

As the original contributor to this existing submission, I request review and acceptance of the issue #507 solution and consideration for any eligible GrantFox OSS compensation under the campaign's actual terms. If eligible and accepted, please confirm the allocation, approved reward (if any), payout procedure and expected payment date. The Maybe Rewarded label does not establish a fixed bounty or payment, and no award is claimed as already approved.

[CemAyyildiz]

This branch now has merge conflicts with main. Please rebase. #527 targets the same issue (#507); only one will be merged, so keeping this one up to date gives it the better chance.

[woahwhattheheck]

@CemAyyildiz The October 1 integration request is addressed on the existing branch. Current head 759f7abea055386903564a1d83d51fdb5ba4d77f includes main@282c75ad933651a93b89a8412ab649b48714c739, and GitHub reports it mergeable.

The non-force integration at ac98b819552a3bd9b88cfe743068f2211cafd1f2 preserves the original #507 contribution and current storage/lifecycle changes. Subsequent commits retain the shared Horizon close-time classifier and canonical receipt/timeline warning copy. The earlier execution evidence remains attached to its original commits; no checks were rerun for this follow-up, and a mergeable branch is not being represented as green CI.

Please re-review the current head and identify any concrete remaining requirement, including the carrier-selection decision alongside #527. I maintain my original #507 contribution claim and request payment. Please confirm acceptance, the compensation amount and settlement route while preserving existing authorship and contributor claims.