fix(compliance-bridge): honor zero balance in ledger providers

[Nussu06]

Summary

GcsLedgerProvider.fetch_balance and ObjectStoreLedgerProvider.fetch_balance resolve a per-account balance with balances.get(account_id, balances.get("default_account", 0.0)) and then fall back to the top-level balance field under if not balance_value. That truthiness test treats a legitimate 0.0 as missing, so a drained account in a multi-account snapshot is reported with the top-level fallback instead of its real zero. The reconciler feeds the CBF an independent cash balance for the barrier h(x) = cash - min_cash, so an inflated balance lets a trade clear against an empty account. Both providers now resolve the balance with explicit membership checks, so a present 0.0 is kept while the absent-account fallback is unchanged.

Type of Change

• feat — new feature
• fix — bug fix
• docs — documentation only
• refactor — no feature/fix, code restructuring
• perf — performance improvement
• test — test additions or corrections
• chore — build, deps, tooling
• ci — CI/CD pipeline
• BREAKING CHANGE — existing behaviour changes

Related Issues / ADRs

N/A

Changes Made

• src/compliance_bridge/reconciliation_worker.py — resolve the ledger balance in both cloud providers via explicit account_id in balances / default_account / top-level balance checks, so a real 0.0 is no longer overwritten by the fallback. Non-zero and absent-account behaviour is identical to before.
• tests/test_reconciliation_worker.py — regression coverage for both providers: a present 0.0 is preserved, a real per-account balance still wins over the fallback, and an absent account still uses the top-level balance.

Testing

• Unit tests added / updated (pytest tests/)
• Integration tests pass (make test-integration)
• Manual smoke test performed (describe below)
• No tests needed (docs/config only — explain why)

Manual test steps (if applicable):

uv run pytest tests/test_reconciliation_worker.py -q
# 26 passed. The two *_present_zero_balance_not_masked cases fail on the
# pre-patch tree (balance resolves to 100000.0 from the top-level fallback)
# and pass after the change (0.0 is kept).
uv run ruff check src/compliance_bridge/reconciliation_worker.py tests/test_reconciliation_worker.py
uv run mypy src/compliance_bridge/reconciliation_worker.py

Compliance & Security Checklist

🔒 Universal — All contributors must verify (all regions affected)

• No secrets, credentials, or PII in committed files
• Network policy unchanged or reviewed by security owner
• OPA policy changes reviewed for correctness (no OPA changes)
• Data residency: no new storage path, GCS write, Langfuse sink, or telemetry export — the change only corrects balance resolution on existing ledger reads
• ISO 42001 / CSA AARM: Lula assertions unaffected
• No region-specific behaviour introduced without a cage_deployment_region guard — the fix is region-agnostic

---

🎯 Region-specific depth — Check only your target deployment

US_FED

• N/A — reconciliation balance mapping is region-agnostic; no NIST control mapping or audit-retention logic changed

EU_ECB

• N/A — not targeting EU_ECB; no new cross-border transfer or High-Risk AI behaviour, GDPR residency preserved

APAC_MAS

• N/A — not targeting APAC_MAS; MAS TRM §4.2 residency preserved, no fairness-relevant behaviour changed

---

📋 Shared-module impact declaration

• Not applicable — PR does not touch shared compliance modules
• Impact assessed across all three regions

Cross-region impact summary (if applicable):

US_FED impact:  none — balance resolution corrected identically; a real 0.0 account balance is now honoured instead of masked.
EU_ECB impact:  none — same correction; no residency or telemetry path change.
APAC_MAS impact: none — same correction; no residency or telemetry path change.

Deployment Notes

N/A