Refactor Accounting: Direction + Route FK + Double-Entry per Phase

[ClaraTersi]

Summary

Refactor the accounting engine to introduce explicit debit/credit direction, route referential integrity, and granular double-entry per transaction phase. All behavior changes are gated behind the existing LedgerSettings.Accounting.ValidateRoutes ledger setting — zero breaking changes for existing ledgers.

Motivation

The current architecture has four limitations:

1. No accounting direction — type (DEBIT/CREDIT/ONHOLD/RELEASE) mixes operation type with direction, making aggregation by cost center impossible
2. ONHOLD affects 2 balance fields — a single ONHOLD operation does Available-- and OnHold++ simultaneously, violating the double-entry principle where each entry affects one field
3. No route referential integrity — the route field is textual with no FK to operation_route
4. No bidirectional routes — reversals require creating a mirrored route instead of reusing the same one

Feature Flag

All behavior changes (double-entry per phase, 1-field-per-operation, counterpart validation) are controlled by the existing ledger setting accounting.validateRoutes, resolved via cache-aside pattern (Redis → DB → permissive defaults). Ledgers without the setting enabled retain exactly the current behavior.