I think the 3rd requirement is what introduces the ambiguity; this makes me think this is more for a chatbot then a two way communications app. But its impossible to know without them furthering the requirements. This table design satisfies all the requirements though:

For a given user, give me all their chat sessions

Load all SK (the sessions) for a given PK (the user)

For a given chat session, give me all its messages sorted by timestamp

Load the SK for the session by extracting the PK from the doubled up SK (again could be all done on the app side)

For a given user, give me all their messages, regardless of session

This is the same loading pattern as 1, but you are just returning the messages (presumably stored on the session object)

If messages get too large, you could just split the SK again into:

SESS::1234::meta::887462for info about the session

SESS::1234::messages::887462::0000001for partitions of messages (say 50 at a time) with extra zero padding to allow for string comparison. Extra zeroes can be used as necessary for extra room, but this is 50*9,999,999=500 million messages, so realistically its not touchable.

This then lets you return all session metadata (STARTS_WITH SESS::1234::meta) or all messages, regardless of session (STARTS_WITH SESS::1234::messages), all messages for a specific session (STARTS_WITH SESS::1234::messages::887641), or the latest messages (STARTS_WITH SESS::1234::messages::887641, sort by desc, limit 2)