fix(sqlite): return an error instead of panicking when decoding an out-of-range INTEGER as PrimitiveDateTime

[breken-ai]

Does your PR solve an issue?

No open issue.

Decoding time::PrimitiveDateTime from an SQLite INTEGER value panics if the value is outside time's range. A common case is a millisecond Unix timestamp, e.g. a column filled from JavaScript's Date.now():

let dt: PrimitiveDateTime = sqlx::query_scalar("SELECT 1700000000000").fetch_one(&mut conn).await?;
// thread panicked at sqlx-sqlite/src/types/time.rs:168:78:
// called `Result::unwrap()` on an `Err` value: ComponentRange { name: "timestamp", is_conditional: false }

The integer branch of decode_datetime calls OffsetDateTime::from_unix_timestamp(..).unwrap(). It has done this since at least 0.7.0. The same file's OffsetDateTime decode uses ? there, and the chrono impls return None, which becomes a decode error. So only PrimitiveDateTime takes down the calling task instead of returning an Err the application can handle.

The fix replaces .unwrap() with ?. It adds a regression test to tests/sqlite/types.rs (it_errors_on_out_of_range_integer_primitive_date_time).

• Before the fix: DATABASE_URL=sqlite://tests/sqlite/sqlite.db cargo test --no-default-features --features sqlite,runtime-tokio,time,macros,migrate --test sqlite-types panics in the new test.
• After the fix: 53/53 pass. cargo test -p sqlx-sqlite --all-features passes, cargo fmt --check is clean, and clippy shows no new warnings in sqlx-sqlite.

I used an AI assistant (Claude) to help find and write this fix. I reviewed the change and ran the tests above myself.

Is this a breaking change?

No. A value that used to panic now returns a decode error. Values in range decode the same as before.

[abonander]

If you rebase it should fix the CI failure.