perf(transactions): add kind to Transaction model and remove expensive Transfer joins in aggregations (#2388)

* add kind to transaction model

* Basic transfer creator

* Fix method naming conflict

* Creator form pattern

* Remove stale methods

* Tweak migration

* Remove BaseQuery, write entire query in each class for clarity

* Query optimizations

* Remove unused exchange rate query lines

* Remove temporary cache-warming strategy

* Fix test

* Update transaction search

* Decouple transactions endpoint from IncomeStatement

* Clean up transactions controller

* Update cursor rules

* Cleanup comments, logic in search

* Fix totals logic on transactions view

* Fix pagination

* Optimize search totals query

* Default to last 30 days on transactions page if no filters

* Decouple transactions list from transfer details

* Revert transfer route

* Migration reset

* Bundle update

* Fix matching logic, tests

* Remove unused code

.cursor/rules/project-conventions.mdc

@@ -66,54 +66,7 @@ All code should maximize readability and simplicity.
   - Example 1: be mindful of loading large data payloads in global layouts
   - Example 2: Avoid N+1 queries
 
-### Convention 5: Use Minitest + Fixtures for testing, minimize fixtures
-
-Due to the open-source nature of this project, we have chosen Minitest + Fixtures for testing to maximize familiarity and predictability.
-
-- Always use Minitest and fixtures for testing.
-- Keep fixtures to a minimum.  Most models should have 2-3 fixtures maximum that represent the "base cases" for that model.  "Edge cases" should be created on the fly, within the context of the test which it is needed.
-- For tests that require a large number of fixture records to be created, use Rails helpers such as [entries_test_helper.rb](mdc:test/support/entries_test_helper.rb) to act as a "factory" for creating these.  For a great example of this, check out [forward_calculator_test.rb](mdc:test/models/account/balance/forward_calculator_test.rb)
-- Take a minimal approach to testing—only test the absolutely critical code paths that will significantly increase developer confidence
-
-#### Convention 5a: Write minimal, effective tests
-
-- Use system tests sparingly as they increase the time to complete the test suite
-- Only write tests for critical and important code paths
-- Write tests as you go, when required
-- Take a practical approach to testing.  Tests are effective when their presence _significantly increases confidence in the codebase_.
-
-Below are examples of necessary vs. unnecessary tests:
-
-```rb
-# GOOD!!
-# Necessary test - in this case, we're testing critical domain business logic
-test "syncs balances" do
-  Holding::Syncer.any_instance.expects(:sync_holdings).returns([]).once
-
-  @account.expects(:start_date).returns(2.days.ago.to_date)
-
-  Balance::ForwardCalculator.any_instance.expects(:calculate).returns(
-    [
-      Balance.new(date: 1.day.ago.to_date, balance: 1000, cash_balance: 1000, currency: "USD"),
-      Balance.new(date: Date.current, balance: 1000, cash_balance: 1000, currency: "USD")
-    ]
-  )
-
-  assert_difference "@account.balances.count", 2 do
-    Balance::Syncer.new(@account, strategy: :forward).sync_balances
-  end
-end
-
-# BAD!!
-# Unnecessary test - in this case, this is simply testing ActiveRecord's functionality
-test "saves balance" do 
-  balance_record = Balance.new(balance: 100, currency: "USD")
-
-  assert balance_record.save
-end
-```
-
-### Convention 6: Use ActiveRecord for complex validations, DB for simple ones, keep business logic out of DB
+### Convention 5: Use ActiveRecord for complex validations, DB for simple ones, keep business logic out of DB
 
 - Enforce `null` checks, unique indexes, and other simple validations in the DB
 - ActiveRecord validations _may_ mirror the DB level ones, but not 100% necessary.  These are for convenience when error handling in forms.  Always prefer client-side form validation when possible.