fix: prevent backdated expense from draining future-dated grant

[odesenfans]

Summary

The eager-write drain in `_consume_address_credits` was filtering lots by the expense's expiration bound only, not by the lower bound on the lot's own `message_timestamp`. Messages can arrive out of order in the P2P pipeline, so a future-dated grant may already exist as a lot in the cache when an older expense lands. Without the lower bound the eager writer happily deducts from a lot that didn't yet exist at the expense's instant.

This is a gap that was introduced in #1122 (the eager-write lot cache PR) and hadn't been spotted before. `_rebuild_credit_lots_for_address` already enforces both bounds because it walks `credit_history` chronologically, so the next restart silently heals any divergence the eager writer produces. The fix brings the eager-write filter to parity with what the replay derives.

Change

One-line filter addition in `_consume_address_credits`:

```python
AlephCreditBalanceDb.message_timestamp <= message_timestamp,
```

Docstring updated to spell out both bounds.

Test plan

• New regression test: backdated expense at T=2024-05 against a grant whose `message_timestamp` is T=2024-06 leaves the grant fully intact (`tests/db/test_credit_balances.py::test_backdated_expense_cannot_drain_future_grant`)
• `hatch run linting:all` passes (ruff, black, isort, mypy, yamlfix, pyproject-fmt, check-sdist)
• CI green on the full credit suite

[foxpatch-aleph]

⚠️ autodev could not generate a review for this PR (empty output from the model).

Click Re-request review to retry.

[foxpatch-aleph]

⚠️ autodev could not generate a review for this PR (empty output from the model).

Click Re-request review to retry.

[foxpatch-aleph]

This PR correctly addresses a gap where backdated expenses could drain future-dated grants in the eager-write credit lot cache. The one-line filter addition (AlephCreditBalanceDb.message_timestamp <= message_timestamp) in _consume_address_credits brings the eager writer's eligibility logic to parity with the chronologically-walked repair replay. The regression test directly validates the fix, and the existing transfer test was adjusted to maintain correctness under the new constraint. The code is well-documented and clean.

src/aleph/db/accessors/balances.py (line 308): Correctly adds the lower bound on message_timestamp. The <= is the correct operator since grants at exactly the same timestamp as the expense should be drainable (the repair replay, which processes entries chronologically, would see the grant before the expense at the same timestamp).

src/aleph/db/accessors/balances.py (line 283): The updated docstring is thorough and clearly explains the rationale for both bounds. Good documentation.

tests/message_processing/test_process_posts.py (line 224): The adjusted timestamp (2022-01-01) correctly seeds the grant before the transfer's time field (2022-04-27), matching the new invariant. The explanatory comment is helpful.