feat: general ledger by account, trial balance as of, members' equity

Three reports a CPA expects that the engine could not produce:

- general_ledger(start, end): the canonical general ledger, organized by
  account in code order. Each account has its beginning balance, every
  posting in the period (date, entry, description, debit, credit, running
  balance on the normal side) and its ending balance, which ties to the
  trial balance. Each posting names its split: the one account on the
  opposite side of its entry, or "-Split-" when that side has several,
  so a compound entry (one debit, several credits) reads correctly from
  every account it touches. The entry-ordered listing the exports called a
  "general ledger" is really the general journal.
- trial_balance_as_of(as_of): a trial balance is always as of a date.
- members_equity(start, end, members): the statement of changes in
  members' equity for a multi-member LLC taxed as a partnership. Each
  member's capital roll-forward: beginning (capital plus their share of
  undistributed earnings), contributions, allocated net income (loss),
  distributions, ending. Allocation is by ownership share to the cent,
  the last member absorbing rounding, so totals are exact and the ending
  total equals balance-sheet equity; any equity change the roll-forward
  can't explain shows as "other" instead of disappearing. Shares must be
  positive and sum to exactly 1; capital accounts must be distinct
  equity accounts (LedgerError::InvalidMembers).
- CashFlowLine.account: the account a line is about, so renderers can
  name members instead of account codes.

Tests (every expectation computed by hand): trial balance as of Jan 31;
February general ledger with beginning balances, running balances, a
card that nets to zero, an inactive account still listed, and every
ending balance tied to the trial balance; a compound entry's splits from
all three sides; a two-member partnership where 666.67 and 100.01 split
unevenly (333.34/333.33, 50.01/50.00), with and without closing January,
tying to the balance sheet each month; bad member configuration.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MtYEaR6M6Ybdhm6X98BWNu

docs/requirements.md

@@ -47,6 +47,24 @@ requirement conflict, the requirement wins.
   reason. Period P&Ls partition: split a range anywhere and the halves sum
   to the whole, and a range's net income equals the change in current
   earnings across it (property-tested).
+- **R-9a — General ledger.** `general_ledger(start, end)`: by account in
+  code order, each with its beginning balance, every posting in the period
+  (date, entry, description, debit, credit, running balance on the account's
+  normal side), and its ending balance, which ties to the trial balance as
+  of `end`. Each posting names its *split*: the one account on the entry's
+  opposite side, or "-Split-" when that side has several (the QuickBooks
+  convention). The entry-ordered listing is the *general journal*, a
+  different report.
+- **R-9b — Trial balance as of a date.** `trial_balance_as_of(as_of)`.
+- **R-9c — Statement of changes in members' equity.** For a multi-member LLC
+  (partnership): each member's capital roll-forward — beginning,
+  contributions (credits to their capital account), allocated net income
+  (loss), distributions (debits), ending — plus a total that equals
+  balance-sheet equity. Earnings not yet distributed (retained earnings and
+  unclosed income) and the period's income are allocated by ownership share
+  to the cent, the last member absorbing rounding, so every row's total is
+  exact. Any equity change the roll-forward doesn't explain is shown as
+  "other", never hidden.
 - **R-10 — Canonical snapshots.** `reports::snapshot()` renders the three
   core reports as deterministic JSON (decimal strings, sorted lines, fixed
   keys). Two engines fed the same books must produce identical output. This