fix(workspace, cli): Bump last_activated_at on conversation use

[JeanMertz]

activate_session_conversation previously only wrote the session mapping; it never updated the conversation's last_activated_at metadata. This meant that jp c use and jp query did not actually refresh the "last worked on" timestamp that drives list sorting, archive cutoffs, and --id=last.

The fix splits the old method into two:

• activate_session_conversation(&ConversationLock, ...) — requires the caller to already hold the conversation lock. It bumps last_activated_at on the metadata and writes the session mapping. Requiring a &ConversationLock makes it a type-level invariant that the metadata write is safe.

• record_session_activation(session, id, now) — the old behaviour: writes only the session mapping, leaving conversation metadata untouched. Used in the lock-contention fallback and in tests that exercise session-mapping logic in isolation.

In jp c use, a non-blocking lock attempt is now made before activating. If the lock is acquired, the full
activate_session_conversation path runs. If another process holds the lock (e.g. a streaming query is in progress),
record_session_activation is used as a fallback so the session mapping is still captured immediately, while last_activated_at is left at the lock holder's recent value — close enough for sorting and archive purposes in the common case.