docs: add receivables financing pattern

[skyc1e]

Adds a short receivables financing pattern note for Arc developers, covering the lifecycle, role and term immutability, state transition guards, token transfer considerations, Arc-specific settlement notes, and a focused test checklist.

I kept this as a design checklist rather than a sample contract so it can be reviewed independently from any particular implementation.

Refs #196.

Checked with git diff --cached --check; no dependency install was needed for this docs-only change.

[osr21]

Nice checklist — this maps closely to a receivables-financing contract I've been running on Arc Testnet (InvoiceFactoring.sol), same three roles and same lifecycle (Created -> Funded -> Delivered -> Repaid, -> Defaulted, Created -> Cancelled). Cross-checking the implementation against this checklist surfaced two concrete follow-ups worth calling out for anyone implementing this pattern:

1. "Update contract state before making external token transfers" — worth emphasizing that this applies to the funding step too, not just repayment. It's easy to write fundInvoice() as pull-from-financier, forward-to-seller, then flip status to Funded, since the "state that matters" (who gets paid) feels like it comes after the transfers. But leaving status flip until after two external ERC-20 calls means a hooked/non-standard token's callback during that forward-transfer could re-enter while status is still Created. Flipping status/recording financier/advanceAmount before either transfer closes that window entirely, at zero extra cost.
2. Worth adding "verify the repayment split can't underflow for the smallest allowed face value" to the rounding test case — with basis-point math truncating on both the advance and fee legs, it's not just about precision loss, it's about proving financierPayout <= faceValue still holds (no revert) when faceValue is a handful of base units.

Both are cheap to add to the checklist/tests and match findings from hardening this pattern for a live testnet deployment. Thanks for writing this up — useful reference either way.