fix(session): preserve the starred flag in AddSession

[kitadesign]

What

SQLiteSessionStore.AddSession built its own INSERT INTO sessions (...) that omitted
the starred column, so the flag was silently dropped on insert. UpdateSession,
addSessionTx and PersistCompaction all set it.

The user-visible effect is on fork: copySessionMetadata copies Starred to the new
session, and ForkSession persists it through AddSession — so forking a starred
session produces an unstarred fork. Reachable from POST /api/sessions/:id/fork and
from the TUI fork path. The in-memory store keeps the flag, so the two backends disagree.

Why this shape

AddSession's INSERT was otherwise byte-for-byte identical to addSessionTx, which
already inserts starred correctly. Rather than adding the missing column to a second
list that can drift again, AddSession now calls addSessionTx. Net -1 line.

This is not a regression: the column list has been missing starred since the starring
feature was added in 875b4dd6 (Jan 2026), and it survived both 345b8aeed
(refactor(session): collapse duplicated session marshalling/SQL) and 93b1673b1
(refactor(session): scan SQL columns into native Go types) untouched.

Test

TestAddSession_PreservesStarred fails on main (Should be true) and passes with the
change. ./pkg/session/..., ./pkg/server/..., ./pkg/acp/..., ./pkg/evaluation/...
and ./pkg/tui/... all pass; go vet is clean.

Context

Noticed while mapping the session schema for #4181 (pluggable persistent session stores).
Happy to fold this into that work instead if you would rather keep it together.

[aheritier]

👋 Some commits in this PR are not signed and verified by GitHub. Please sign your commits with a GPG or SSH key registered in your GitHub account, then force-push.

Commits that are not verified: 63e8c0f

See GitHub's guide on signing commits for setup instructions. I've added status/needs-signed-commits; it will be removed automatically once every commit in this PR carries a valid GitHub-verified signature.

[kitadesign]

Thanks — sorry for the noise. The signature was in place, but I registered the SSH signing key on my account about two minutes after the check ran, so 63e8c0f was still showing as unverified at that moment.

I've since force-pushed (identical tree, re-signed): fcab72f8b now reports verified: true / reason: valid via the API. The status/needs-signed-commits label looks stale rather than accurate — happy to do anything else if the check needs re-triggering.