[19.0][FIX] auditlog: flush pending recomputations before swapping the cache

[skanndar]

Fixes #3635.

With a full-log rule on account.move, registering a payment leaves the payment's liquidity move line with amount_residual / amount_residual_currency / reconciled set to NULL in the database. The outstanding-credits widget domain (_compute_payments_widget_to_reconcile_info) ends in '|', ('amount_residual', '!=', 0.0), ('amount_residual_currency', '!=', 0.0); with both columns NULL neither leg matches, so the payment is never proposed as an outstanding credit on the invoice. We hit this in production and reproduced it on a virgin database with only account (demo data) + auditlog.

What the trace shows (instrumenting the transaction state around ThrowAwayCache and peeking at the database at each step):

1. When write_full() performs the old-values read inside ThrowAwayCache, the payment's move lines still have pending recomputations of their stored computed fields in transaction.tocompute.
2. The context manager itself restores tocompute intact on exit. But after this swap/read/restore cycle, those pending recomputations are consumed during the subsequent write.origin + flush_recordset() without being persisted: they leave tocompute, never appear in field_dirty, and the database columns remain NULL.
3. The receivable counterpart line happens to be healed later by the reconciliation's own recompute; the liquidity line is never recomputed again, so its columns stay NULL forever.

With a Fast log rule (no ThrowAwayCache) the very same flow marks the lines dirty and they reach the database.

The fix makes the swap safe by flushing everything still pending right before setting the cache aside, in ThrowAwayCache.__enter__: with nothing pending, there is nothing the swap can lose, and the values read for the log are read after the pending state is persisted. env.flush_all() is broader than the strict minimum, but this is a correctness fix and the flushed work is work the transaction had to do anyway.

Includes a regression test (post an invoice → register a payment with a full-log rule on account.move → assert the payment lines' stored computed columns are not NULL). It fails on current 19.0 with AssertionError: unexpectedly None : line ...: amount_residual is NULL and passes with the fix; the whole auditlog + test_auditlog suite is green (58 tests).

May also be related to #3638 (same disposable-cache family); not verified.