Fix --continue to resume most recently used conversation (#1140)

[PriyanshAroraa]

Fixes #1140.

Problem

`llm --continue` picks the conversation with the newest `id`, which means a freshly-created conversation will always shadow an older one you have just been chatting in.

Reproduces with:

llm "start a"                          # creates conversation A
llm "start b"                          # creates conversation B  (newer id)
llm --cid <A> "continue a"             # A now has the most recent response
llm -c "continue again"                # BUG: resumes B, not A

Same issue reported by a second user in the comments of #1140 ("instead continued the most recently created new conversation, instead of the last used one. Pretty counter intuitive.").

Fix

In llm/cli.py load_conversation(), instead of sorting the conversations table by id desc (creation time), pull the conversation_id off the most recent row in the responses table. Response IDs are ULIDs that sort chronologically, so "newest response" == "conversation the user last used".

Before:

matches = list(db["conversations"].rows_where(order_by="id desc", limit=1))
if matches:
    conversation_id = matches[0]["id"]

After:

last_response = list(
    db["responses"].rows_where(
        select="conversation_id",
        order_by="id desc",
        limit=1,
    )
)
if last_response:
    conversation_id = last_response[0]["conversation_id"]

Test

Added test_llm_prompt_continue_uses_most_recently_used_conversation in tests/test_llm.py that reproduces the bug scenario — creates A, creates B, resumes A via --cid, then asserts --continue resumes A rather than B.

• Test fails without the fix (as expected — that's the bug)
• Test passes with the fix
• Full suite: 449 passed, 0 regressions (1 pre-existing collection error in test_encode_decode.py unrelated to this change)

Notes

• Behavior is unchanged for the common single-conversation case — the last response belongs to the only existing conversation.
• Behavior is unchanged when --cid is passed explicitly.
• Slightly more restrictive when the DB has conversations but no responses (returns None instead of an empty conversation object). In practice a conversation without responses shouldn't exist, but happy to add a fallback to the old behavior if you want to keep that edge case.