fix(libsql): parse scientific notation cost aggregates

[serrrfirat]

Summary

• fix libSQL user/admin usage cost aggregate parsing when SQLite emits scientific notation (for example, 7.5e-05)
• cover the /api/admin/users caller path with a tiny-cost regression test

Root cause

The failing E2E job returned 500 from /api/admin/users because libSQL CAST(SUM(l.cost) AS TEXT) can produce scientific notation for small costs. rust_decimal::Decimal::from_str_exact rejects exponent notation, so user_summary_stats surfaced invalid cost value '7.5e-05'.

Verification

• cargo fmt --check
• cargo test --lib --no-default-features --features libsql test_admin_user_list_handles_tiny_costs_from_libsql -- --nocapture
• cargo test --lib --no-default-features --features libsql test_user_summary_stats_with_jobs_and_costs -- --nocapture
• cargo test --lib --no-default-features --features libsql test_user_usage_stats_with_calls -- --nocapture
• cargo test --lib --no-default-features --features libsql test_admin_usage_summary_aggregates_in_db -- --nocapture
• python -m pytest scenarios/test_settings_search.py::test_search_filters_user_rows -q (via Python 3.11 venv)
• cargo check --no-default-features --features libsql -q

Risk

Low: scoped to libSQL parsing of text-rendered aggregate decimal values; PostgreSQL paths are unchanged.

[gemini-code-assist]

Code Review

This pull request introduces a helper function parse_libsql_decimal_text in the libSQL backend to correctly handle decimal values that may be returned in scientific notation, particularly for very small costs. Several locations in the database layer were updated to use this new parsing logic. Additionally, a regression test was added to ensure the admin user list API can process these small cost values without error. I have no feedback to provide as there were no review comments.