Accounting: partymap mode + register payee backfill

Adds "partymap" mode to buildium-payee-backfill: resolves each Buildium GL
transaction to a local vendor (by name) / customer (by unit_number) and stages
it in accounting.buildium_party_map. The materialized bank register
(accounting.transactions) is then backfilled in SQL by bridging each register
row to its journal-entry bank line (bijective row-number pairing within
date/amount/side groups, so same-amount/same-day payments each get a distinct
owner) and pulling the resolved vendor/customer + name from staging.

Applied to all five Buildium-imported associations (Village Woods, Bent Oak,
Village Grove, Bridgewater, Casuarina).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

supabase/migrations/20260615180000_buildium_party_map_staging.sql

@@ -0,0 +1,19 @@
+-- Staging table for the Buildium payee/payor register backfill.
+-- Maps a Buildium GL transaction id to the resolved local vendor/customer and
+-- the party name, so the materialized bank register (accounting.transactions)
+-- of imported-GL companies can be backfilled by bridging transaction → journal
+-- entry (by bank line) → this map. Populated by the buildium-payee-backfill
+-- edge function ("partymap" mode).
+create table if not exists accounting.buildium_party_map (
+  company_id uuid not null,
+  external_id text not null,
+  party_name text,
+  vendor_id uuid,
+  customer_id uuid,
+  party_type text,
+  updated_at timestamptz not null default now(),
+  primary key (company_id, external_id)
+);
+
+comment on table accounting.buildium_party_map is
+  'Staging: Buildium GL transaction id -> resolved local vendor/customer + name, used to backfill the materialized bank register (accounting.transactions) for imported companies.';