Fix local sign-in losing its user account (empty read-only workspace)

[iyernaveenr]

Problem

In fully local (self-hosted) mode, the app can end up showing only an empty, read-only "Legacy Space": no Projects in the sidebar, composer disabled with "Legacy Spaces are read-only", and no way to pick a model -- even though all of the user's Spaces, Projects, and chat history are intact on the server.

Root cause

The local auto-login endpoint (POST /api/v1/user/auto-login) returns only token and email -- no user id. The client's setAuth therefore stores user_id: null. Space hydration filters server Spaces by ownership, comparing each Space's user_id against the canonicalized local id; with no id, the canonical value is the local sentinel, which matches nothing, so every server-owned Space is silently discarded and only the locally fabricated legacy Space remains. The access token itself carries the user id in its payload the whole time; the client just never read it.

Fix

• Server: include user_id in the auto-login response (LoginResponse gains an optional user_id).
• Client: when a login response omits the id, recover it from the access token's payload in setAuth (defensive for all login paths).
• Client: repair already-persisted sessions at rehydrate -- an existing install with a stored token but no stored user id recovers the id from the token at startup, without requiring the user to sign in again.

Testing

• Reproduced the degraded state (persisted user_id: null, valid token): Space list showed only "Legacy Space" while an authenticated /api/v1/spaces request returned all Spaces. After the fix, reloading the app recovers the id from the token and the user's Spaces and Projects reappear.
• POST /api/v1/user/auto-login now returns user_id (verified against a running local server).
• tsc passes; the changed server files compile; store test suites pass. Token-decoding helper handles malformed/absent tokens by returning null (no behavior change for the hosted login path, which already supplies an id).