Extend receiver functionality

[yongqjn]

Summary

• add per-job payoutReceiver support so provider authorization is separated from provider-side payout custody
• route provider-side net payouts to the provider by default, or to payoutReceiver when configured
• add IDisburser.onDisbursement(jobId, selector, token, amount, data) callback support for receiver contracts that advertise the interface via ERC-165
• allow EOAs, smart accounts, and plain contracts as payout receivers without requiring a callback
• update architecture docs and tests for default provider payout, receiver payout, callback, non-callback, and revert behavior

Design Reference

This follows the Payout Receiver design described in HackMD:
https://hackmd.io/@nicholas-okx/HkBJoKY0Wg

The design goal is to avoid treating the provider as both the operational actor and the payment recipient. A job can keep provider as the actor authorized to submit work, while payoutReceiver receives provider-side funds. This supports wallet segregation and custom downstream fee routing without forcing one static ACP fee model.

Behavior

• payoutReceiver == address(0): ACP pays the provider and does not call onDisbursement
• nonzero EOA or plain contract receiver: ACP pays the receiver and does not call onDisbursement
• nonzero receiver contract advertising IDisburser: ACP pays the receiver, then calls onDisbursement after the ERC-20 transfer
• callback reverts propagate and roll back complete
• refunds and platform/evaluator fee routing are unchanged

Scope note: this PR applies the payout receiver behavior to the current complete disbursement path. settle is out of scope for this branch.

Testing

• npm test
• 15 passing