Sales Invoice + Jurnal Integration

Adds a per-organization flag (is_download_order_si_jurnal, stored in the existing organization_packages.extras jsonb column — no migration) that gates a "Download SI" (Sales Invoice) action on the self top-up invoices view. When on, a client can download a paid order's Mekari Jurnal Sales Invoice; if Jurnal has no SI for that order, the UI falls back to the existing local invoice PDF. Both endpoints (downloads-jurnal, downloads/:order_id) already exist — no new download API. Supersedes the PRD's original client_configs/is_auto_invoice_enabled storage choice and drops the PRD's "Download SO" (pending-order) scope — see the RFC's 2026-06-30 scope clarification.

Scope Changes

• Backend — reuse organization_packages.extras (jsonb key, no migration) via the existing PUT /billings/extras write path and GET /billings/info passthrough; add a bounded timeout to the existing Jurnal SI-fetch call; open authorization question on who may toggle the flag (RFC Decision 2 / OQ-2 — infosec sign-off pending)
• Frontend — "Download SI" button on InvoicesListPage.vue (hub-chat) for paid orders when the flag is on; calls the existing downloads-jurnal endpoint and falls back to the existing local invoice PDF on a null URL. Design pending (no Figma yet) — not part of this RFC's execution-ready scope; needs a hub-chat consumer RFC.

Initiatives

• prds/sales-invoice-jurnal.md — PRD: Integrate Sales Invoice with Jurnal
• rfcs/sales-invoice-jurnal.md — RFC: is_download_order_si_jurnal flag — backend half agent-execution-ready; frontend half a documented consumer contract pending a hub-chat RFC + design

QA Lane

Lane B — keeps a human QA gate. Billing-document critical: the SI button surfaces on a payment flow — a broken download or wrong toggle state leaves clients without an accounting document and triggers Finance support escalations. No E2E test specs exist for this initiative yet. Pending classification by QA.