Sales-query read API over chestshop_sale (by firm / owner, paginated + filtered + aggregated)

Part of PAR-175 (firm sales commands). The enabler — every command below needs a read path into chestshop_sale.

Today MarketApi is write-only (verified: only recordSale/upsertShop/deactivateShop/updateShopStock, all void), and ChestShopMarketMapper is annotation write-only (@Insert/@Update; no @Select). The in-game sales commands run inside business-rian / treasury-api-plugin and need a server-side read surface.

Do: add a sales-query read API (extend MarketApi or a new SalesQueryApi in treasury-api), implemented in treasury via a new read mapper (the existing ChestShopMarketMapper is write-only — either add @Select methods to it or, cleaner, a new ChestShopSalesReadMapper). Query chestshop_sale:

• By owner scope: firm (shop_firm_id — denormalized directly on the row, so no firm→account resolution needed; PAR-14 is NOT a dependency), personal owner (shop_owner_uuid_bin), or shop_account_id. Guard on shop_account_type='BUSINESS' where it matters.
• Pagination: page/offset + limit (legacy used 10/page).
• Filters: time window (last N days), direction (BUY/SELL), item_key/material, customer_uuid.
• List rows: time, direction, customer, qty, item name, unit + total price, tax, location, txn_id.
• Aggregates: count, total volume, total tax, units, top items, top customers over a window — backing /firm sales summary.

Use the existing indexes (idx_cs_firm, idx_cs_owner, idx_cs_acct, idx_cs_item, idx_cs_customer, idx_cs_time). Mirror existing read logic: treasury-rest-api already reads these tables via io.paradaux.treasuryrestapi.mapper.ChestShopMapper — reuse its SQL shapes. Keep it a read DTO — no money mutation. Mind the financial-privacy posture: per-customer/per-seller drilldowns are sensitive (PAR-116 deliberately kept these out of the public REST surface; this is the authenticated, staff-gated in-game path).