feat(up): build deterministic Transfer from relationships.transferAccount

[threatsurfer]

Follow-up from #2460.

#2460 honours Up's relationships.transferAccount by importing internal movements (and round-ups) as funds_movement, and stores the counterpart account id in extra under the up key, keeping transfers out of income, expense, and budgets.

For two-sided transfers between two linked accounts, Family#auto_match_transfers! still pairs the entries into a proper Transfer using its amount/date/currency heuristic. The stored transfer_account_id is a deterministic hook to do better: build the Transfer record straight from Up's own link rather than relying on the probabilistic matcher.

Proposed

• On import (or in a post-sync pass), when a transaction has a transfer_account_id and the counterpart Up account is also linked in Sure, create the Transfer directly between the two entries (mapping transfer_account_id to the linked Sure account) instead of leaving it to auto_match_transfers!.
• This avoids false pairings from the heuristic and handles round-ups and identical-amount transfers reliably.

Notes

• One-sided movements (counterpart not linked in Sure) cannot be paired and correctly remain funds_movement.
• Happy to take this on once feat(up): flag internal transfers and round-ups as funds_movement #2460 lands.

[threatsurfer]

I ran the numbers on my own Up dataset to size this before proposing an approach.

Of the transferAccount transactions in a recent snapshot:

• 303 total, 302 two-sided (counterpart account also linked in Sure), 1 one-sided.
• ~16.5% (50) fall in ambiguous groups where several entries share the same amount and date (e.g. 6 entries of $2.00 on one day, 6 of $1.01 on another). These are small recurring inter-account transfers, not round-ups (round-up amounts vary and rarely collide).

Worth being precise about the value: after #2460 both sides of these are already funds_movement, so the budget/analytics treatment is already correct. What the family-wide amount+date matcher can get wrong in those ambiguous groups is the Transfer record's attribution, i.e. it may link the wrong inflow to the wrong outflow (Spending to Cars for a transfer that actually went to Travel). transferAccount names the exact counterpart account, so it deterministically disambiguates the pairing. So this is a transfer-attribution accuracy improvement (~16.5% of transfers), not a budget fix.

Two ways I could implement it, and I would rather get your call on direction before building:

Option 1 - Up-contained post-import pass. After importing an item's transactions, for each entry with a transfer_account_id whose counterpart Up account is also linked, find the opposite-amount entry on that specific counterpart account and create the Transfer directly. auto_match_transfers! then skips it via the existing existing_transfers guard. Keeps the change entirely inside the Up provider and does not touch auto_transfer_matchable, but it duplicates a little matching logic and runs independently of the shared matcher.

Option 2 - Make the shared matcher transferAccount-aware. Teach auto_transfer_matchable (or a pre-pass) to prefer a provider-supplied counterpart-account hint when present, constraining the candidate pairing to the identified account pair. More reusable across providers, but it changes shared cross-provider machinery.

I lean Option 1 for a first cut (self-contained, low blast radius), with Option 2 as the more general direction if you would rather bake it into the matcher. Happy to build whichever you prefer, to hold, or to agree it is not worth the complexity given the budget win is already banked.