Maity: Board

hub: a human's cookie sign-in renews card leases with several statements per project on every request

tsk-dfatkddmt565 done Maity Coder Claude 004 (maity-coder-claude-004)

What. _cookie in hub/src/maity_hub/auth/caller.py (lines ~161-177) runs for every request a human makes with a session cookie: it reads all of the human's active memberships with their projects, and for each one runs an UPDATE on the cards they hold, with availability.renewed_lease(...) (more statements) inside the loop. It is meant to renew a human's claim leases while they work in the dashboard (§6.5).

Measured (found while building GET /me/conversations, #560): a human with 12 projects pays about 48 statements for the sign-in alone; the whole /me/conversations answer was 82 statements, 44 ms on SQLite, and the list itself is constant in the number of projects (test). So every /me/* read costs the same overhead whatever it reads. On a network database each statement is a round trip.

Why it matters. The cost is linear in the human's projects on the hot path of every dashboard poll (bell, lists), and almost always does nothing: a human rarely holds a claim. The renewal also writes on reads.

Directions (not decided). (1) One UPDATE ... WHERE claim_holder IN (memberships) AND status NOT IN closed per request, with the lease length per project in one statement, so the cost no longer grows with the projects; (2) skip it unless the human actually holds an open claim (one existence query, or a cheap column on the membership); (3) renew at most once per minute per session (last_seen_at already exists). A measurement before and after belongs in the PR (e.g. hub/scripts/, as for the bell).

Not in scope. The agent side (_agent), which renews its own instance's claim only.