fix(reports): foot subtotals by calculation weight, not a plain sum

[jfrench9]

Summary

_check_totals_foot summed a subtotal's presentation children with no regard to balance type. A debit-nature child under a credit-nature subtotal — interest expense under Nonoperating Income, a contra under Revenues, accumulated depreciation under PP&E net — was counted with the wrong sign, and the check reported a "difference" on a subtotal the calc DAG had computed correctly. Surfaced the moment #1303 started naming columns: on Harbinger's FY2025 income statement, [2025-12-31] Subtotal 'Nonoperating Income (Expense)' (-4484.45) does not match sum of children (3026.95), difference: 7511.40 — exactly 2 × the 3,755.70 interest expense. The subtotal was right; the check was wrong.

Change

• Income-statement and balance-sheet rows are natural-signed per element, so the foot check now applies XBRL's calculation-weight rule: a child whose balance type differs from its subtotal's enters with weight −1; agreeing or unknown balance types enter +1 (_child_weight).
• Cash-flow rows are cash-effect signed by _derive_cash_flow_facts / _reconcile_operating_to_cash and foot as a plain sum by construction, so _validate_cash_flow passes sign_by_balance=False.
• Warning-only either way; passed / status are unaffected.

Tests

Five new cases in test_guard_rails.py::TestTotalsFoot: the Harbinger FY2025 nonoperating section verbatim (no warning), the same shape with a genuinely wrong subtotal (one warning, right numbers), contra-revenue under Revenues, accumulated depreciation under PP&E net, and Harbinger's July 2026 operating section footing as a plain sum on the cash flow.

just test-code clean; tests/operations, tests/routers/extensions, tests/middleware/mcp — 4,986 passed.