Assign one accounting class to a batch of transactions, posted rows included

Sets the class on up to 100 transactions per request (#2125; each row is its own database transaction, and a batch must finish inside the 30s request timeout). Each row goes through the same audited assignment as PATCH /accountant/companies/{customerId}/transactions/{transactionId} with only classId: the transaction and its owned journal_lines get the class and one transaction.class_assignment audit_logs row is written, in one database transaction per row. Amounts, accounts, dates and posting status never change, and nothing is voided. A row in a filing-locked period, a reconciled row, or a row whose journal entry has an ambiguous source is reported as failed with the reason, and the rest of the batch still runs. Rows already on the class are skipped, so re-running a request is safe. An inactive or foreign classId is refused with 404 before any row is touched. To class a date range (for example the last N months), page transaction ids with GET /accountant/companies/{customerId}/transactions?dateFrom=&dateTo= and send them in batches of 100 or fewer. To clear a class, use the single-row PATCH.