fix: make government account resolution symmetric across transfers and balance checks

[md5sha256]

Follow-up to #17. Branched from main, independent of the notification-adapter work.

Problem

#17 made the recipient side of TreasuryEconomyProvider.transfer prefer a party's GOVERNMENT account over their PERSONAL one, so rent from a government-owned leasehold lands in the government treasury.

The paying side was never changed. transfer still resolved the payer with treasuryApi.resolveOrCreatePersonal(fromId) unconditionally, so when the government is the payer the money came out of the entity's personal balance instead of the treasury the rent went into. That happens on every lease-termination refund, which is landlordId → tenantId:

• Realty.java:509 — scheduled terminations refunding prepaid-but-unused time
• RealtyPaperApiImpl.java:483 — the defensive refund when the backend update fails

Net effect: renting a government region credits the treasury, un-renting it debits the personal account. The treasury only ever grows.

getBalance had the same asymmetry from the other direction — it used getBalanceByOwnerUuid, which does not apply the preference at all, so an affordability check on a government entity inspected a different account than the payment it gates would touch.

Fix

One preference, applied everywhere: GOVERNMENT > PERSONAL > BUSINESS > first-available.

• Extracted preferredAccount(List<Account>), returning empty when the party holds no accounts.
• transfer resolves both payer and recipient through resolveAccount, which falls back to resolveOrCreatePersonal when there are none.
• getBalance uses the same preference and reads getBalanceByAccountId. It keeps its no-account-means-zero contract and deliberately has no create-if-missing fallback — a balance read must not have the side effect of opening an account.

Ordinary players are unaffected: with no government account they still resolve to PERSONAL, and a firm proprietor still pays from their personal balance rather than a BUSINESS account owned by their own UUID (the leak #17 originally fixed).

Tests

Written before the fix; all failed first, all pass now. TreasuryEconomyProviderTest: 11 tests, 0 failures, full :realty-paper:test green.

New payer-side coverage mirroring the existing recipient-side cases:

• governmentPayer_refundIsDebitedFromGovernmentNotPersonal
• firmProprietorPayer_paysFromPersonalNotBusiness
• payerWithNoAccounts_resolvesOrCreatesPersonal

New balance coverage:

• governmentBalance_readsTheGovernmentAccountNotPersonal
• firmProprietorBalance_readsPersonalNotBusiness
• balanceWithNoAccounts_isZeroAndCreatesNothing — asserts resolveOrCreatePersonal is never called
• balanceOfNull_isZero

The existing recipient-side test helper was reworked to stub the payer through getAccountsByOwner rather than resolveOrCreatePersonal, matching the new resolution path.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SUskvuegwBzQMufaYxp5eM