SqliteSessionService.list_sessions() has the same missing ORDER BY as #6272

[Q01P]

Describe the bug:
Same bug class as #6272, in the SQLite backend. SqliteSessionService.list_sessions() (src/google/adk/sessions/sqlite_session_service.py, L298–315) fetches sessions with two raw SELECT ... WHERE queries and no ORDER BY, so row order is whatever the query plan returns and sessions[-1] for "latest session" is undefined behavior. The existing sqlite tests compare order-blind, so this was never caught.

#6276 fixes this for DatabaseSessionService only its diff doesn't touch the sqlite service, leaving the two backends with inconsistent contracts.

To Reproduce:
Create sessions A, B, C in that order, then update A so it has the newest update_time. list_sessions() returns:
Returned order:
id=A last_update_time=1784563266.526278
id=B last_update_time=1784563266.420852
id=C last_update_time=1784563266.473127

Returned id order: ['A', 'B', 'C']
Expected ascending-time order: ['B', 'C', 'A']
A is last (newest activity)? False
Order matches update_time asc? False
Order follows insertion (primary-key scan), not activity.

Expected behavior:
ORDER BY update_time ASC with stable tie-breakers, the contract per the discussion in #6272, implemented in #6276 (update_time rather than create_time, since orphan sessions can be newly created but stale in activity). update_time is already in the SELECT column list.

PR incoming.

[surajksharma07]

@Q01P Confirmed — same missing ORDER BY as #6272, just in the SQLite backend this time.
PR #6432 and the update_time reasoning (orphan sessions can be newly created but stale in activity) both check out against the code.

One thing worth settling before it merges: #6276 for the other backend sorts by create_time, not update_time — worth pinging that reviewer so both backends land on the same ordering contract rather than trading one inconsistency for a smaller one!