Branch reporting

MER-07 local sandbox supports up to 100 permanent branch records per merchant, including archives. Owner/Admin members create branches with a unique permanent code and a name. Names can change while active. Archiving is irreversible and prevents new payment attribution; it does not cancel existing links or alter historical payments. Other active members can read branches and their reports.

Use fresh membership context on GET/POST /portal/merchants/{merchant}/branches and POST /portal/merchants/{merchant}/branches/{id}. Mutations require Idempotency-Key; changes include expected_version, name and state. A normalized identical command returns its original result; changed payload conflicts. Revoked/demoted members cannot replay management commands. Audit records accompany successful commands.

Pass optional branch_id to payment or payment-link creation. The API resolves ownership and copies code/name from the branch. External trusted-header impersonation cannot override that snapshot. A later rename/archive never rewrites the payment. An exact original create retry still succeeds after archive; a new create against that archived branch fails. Omitted/null branch_id leaves a payment unassigned and preserves pre-existing request idempotency fingerprints.

The payment list, dashboard and CSV/XLSX export accept branch_id=<UUID> or branch_id=unassigned. Omit it for all merchant payments. Archived branch history remains searchable. CSV/XLSX include the original branch ID/code/name; money stays in exact minor units and currency totals remain separate. A cursor belonging to another branch is rejected when a branch filter is applied. Portal reporting and new-link forms expose these selections.

Optional branch settlement accounts and routing are not implemented in this increment. They depend on MER-03 account verification and settlement-routing work. All accounts, payments and evidence remain synthetic; these controls do not enable live mode.