Session ids are sequential integers; plan the move to a non-guessable id

#5733 consolidated the three session stores into one, keeping the integer autoincrement primary key so the existing contracts stayed untouched. That key shape is now isolated behind one seam, which makes changing it a bounded piece of work — this issue tracks doing so.

Why change it

Sequential ids are predictable. The securecookie HMAC means a bare id is not enough to forge a cookie, so this is defense-in-depth rather than a live hole — but the raw id travels further than the cookie:

• the Kubernetes terminal writes it into a pod annotation, readable by anyone with pod read access in that namespace
• session_data rows carry it as a plain string column

A non-guessable id removes the value of both exposures.

What the change touches

The integer shape is load-bearing in exactly three places (documented in the sessionstore package comment):

• api.SessionDataStore.IsValidSession(id int)
• the session_data join: CAST(id AS varchar) against the sessions table
• plugins/kubernetes/terminal/cleanup.go — annotation round-trip via strconv.Atoi

Sketch

Generate a random id (128-bit, hex or base64url) in the store at insert; the id column becomes a string type with a unique index; the three call sites move from int to string — the CAST disappears rather than moves. Migration recreates the table, so the cost is the same one-time sign-out #5733 already established, and kube-terminal pods annotated with old ids are reaped by the existing cleanup.

Start with the sessionstore package comment and trace api.SessionDataStore.IsValidSession, the session_data join, and plugins/kubernetes/terminal/cleanup.go. Check the migration approach established by #5733 and verify the insert, annotation round-trip, and cleanup paths. Done means session ids are non-guessable strings, the CAST and strconv.Atoi paths are removed, and old annotated ids are still reaped.