Publish GitHub invoices through CoinPay with safe retries

[phucnguyen1707]

Summary

• Add the explicitly enabled /coinpay create @payer <amount> "description" flow: create an API-idempotent draft, publish it without email, and post the live CoinPay link only after validating the response.
• Keep the existing numeric-first command separate. Accept human commenters without a role allowlist, while retaining amount/source caps, strict validation and immutable repository/comment identity.
• Never move funds, mark an invoice paid, revive a closed invoice or select an arbitrary receiving wallet.
• Include a side-effect-free dry-run preview, safe actionable errors, and rollout guidance for open usage, public-origin matching and quota boundaries.
• Accept fractional-cent activation fees returned by Portal, so valid invoices such as $20.13 at 1% do not publish successfully and then lose their bot reply. Principal validation still requires whole USD cents; fee and payment policy are unchanged.

Validation

• Node 24: 215 unit/contract/flow tests, TypeScript and deterministic Action bundle passed.
• 35 additional localhost integration tests passed against the actual bot, Portal create/publish handlers and isolated PostgreSQL migrations. Authentication, payment provider and GitHub transport are synthetic; no full deployed Next/Supabase or real checkout claim is made.
• Independent implementation and incremental reviews completed.
• No live invoice, email, GitHub command comment or payment was used for testing.

Dependency And Limitations

Draft for review; githubInvoices.enabled remains false.
Requires the Portal invoice-creation idempotency API/migration and its existing publish endpoint. Deploy/verify that foundation separately before enabling.
Portal dependency: profullstack/coinpayportal#319
Invoices belong to the repository-configured CoinPay business, NOT the commenting user's personal account. The payer mention is a notification/reference, not a verified CoinPay client. Account linking, PDF generation and payment-status webhooks are not implemented in this slice.
Open usage can create unwanted invoices/mentions. Invoice publishing does not share the legacy payment route's monthly quota check; the owner must accept that boundary before rollout.