Ensure no ordinary SQL ordering exists

The SQLite store preserves account nonces through `u64_to_value`/`column_value_as_u64` (because columns are stored as `i64`), but `prune_account_history()` compares the encoded `replaced_at_nonce` values directly in SQL using `<=`.

SQLite treats those values as signed `i64`s, so the ordering breaks once the nonce exceeds `i64::MAX`.

That would cause history rows to be pruned incorrectly because the value will be incorrectly encoded. We should either make the SQL comparison unsigned-aware or decode the values and compare them in Rust, with tests around the edge cases.

This is quite low priority because these limits are practically hard to hit but we should make it as correct as possible.

Look at the SQLite store implementation, specifically the `u64_to_value`/`column_value_as_u64` functions and the `prune_account_history()` method. The issue is about comparing unsigned 64-bit nonces in SQL where they are stored as signed i64. You need to understand how the nonce encoding works and then either adjust the SQL comparison to be unsigned-aware or move the comparison logic to Rust. Write tests for edge cases, especially around the i64::MAX boundary.

Rédigé par le modèle d'indexation à partir du texte de l'issue.