fix: allow session id reuse after delete

[QuentinBisson]

Fixes #2279.

What

DeleteSession soft-deletes, but UpsertSession's ON CONFLICT update never cleared deleted_at, so recreating a previously deleted session id upserted an invisible row: the create handler's own reload failed with 500 "Failed to load created session", forever. This breaks any client that derives session IDs deterministically from an external key.

UpsertSession now resurrects a soft-deleted (id, user_id) as a fresh incarnation, in one statement:

• clears deleted_at and restarts created_at
• soft-deletes the previous incarnation's events and owned tasks, and drops its shares, so the recreated session starts empty instead of inheriting the old history

NULL-owned tasks are left alone: the created_at restart already hides them from the new incarnation via the ownership bound in tasks.sql, and they may still resolve to another user's same-id session. Upserts of live sessions are unchanged (no purge, created_at preserved).

Tests

TestSessionRecreateAfterDelete (recreate succeeds; events/tasks/shares empty; another user's same-id session untouched) and TestUpsertLiveSessionKeepsHistory (no purge / no created_at reset on live upsert).

[Copilot]

Pull request overview

This PR fixes a correctness issue in the Go/Postgres persistence layer where a session ID could not be reused after a soft delete. It updates the UpsertSession SQL to properly “resurrect” a soft-deleted (id, user_id) session while preventing the recreated session from inheriting prior history.

Changes:

• Update UpsertSession to clear deleted_at, reset created_at only when resurrecting, and purge prior incarnation data (events, owned tasks, shares) in the same statement.
• Regenerate SQLC outputs to reflect the new query and add doc comments on the generated Go interface/methods.
• Add database client tests covering session recreation after delete and ensuring live-session upserts preserve history.

Reviewed changes

Copilot reviewed 2 out of 4 changed files in this pull request and generated no comments.

File	Description
go/core/internal/database/queries/sessions.sql	Adjusts UpsertSession to resurrect soft-deleted sessions and purge prior data atomically.
go/core/internal/database/gen/sessions.sql.go	SQLC-generated Go wrapper updated for the new UpsertSession query and docs.
go/core/internal/database/gen/querier.go	SQLC-generated interface comment updated for UpsertSession.
go/core/internal/database/client_test.go	Adds tests validating recreate-after-delete behavior and no-op behavior for live upserts.

Files not reviewed (2)

• go/core/internal/database/gen/querier.go: Generated file
• go/core/internal/database/gen/sessions.sql.go: Generated file

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[iplay88keys]

Discussed a similar case in this thread, related to resurrecting tasks.

[QuentinBisson]

Thanks for the pointer, hadn't seen that thread. Having read it, I think sessions warrant the opposite choice from tasks.

Tasks have generated ids and an id-only PK, so permanently deleting an id costs nothing and closed a real cross-user takeover race. Sessions are the inverse: #2279 exists precisely because clients derive session ids deterministically from an external key (contextID), so an id that stays deleted forever would permanently brick recreate for that key. And the conflict target here is (id, user_id), so a resurrect only ever touches the caller's own row; the cross-user surprise from the tasks thread can't happen.

Given that, I see two reasonable designs:

1. Resurrect with purge (this PR): clear deleted_at, restart created_at, and soft-delete the old incarnation's events/tasks/shares in the same statement. The recreated session starts empty, so for the caller it's indistinguishable from a fresh session. Keeps soft-delete semantics for everything else.
2. Hard delete sessions: if nothing actually reads soft-deleted session rows back, the soft delete is pure liability and the fix collapses to a plain DELETE, recreate becomes a normal insert. Happy to switch to this if that's the case, it's the simpler change.

I went with 1 because it doesn't change delete semantics and I didn't want to assume the retention question. Are you okay with this solution?