feat: roles SPA Users, Profile, API keys, Activity

docs/api.md

@@ -414,10 +414,21 @@ A user has exactly one stored role, `role_id`, and nothing else: there is no `ro
 `email`, `is_verified`, `created_at`, `updated_at` and `display_name` in every response that includes a user (login,
 verify, register, invite accept, `GET /v1/auth/me`); `GET /v1/auth/me` adds `author` and `access`.
 
+`role_assigned_by` is `{ id, name }` or `null`: who last set the user's role. It is stored as the nullable column
+`role_assigned_by_id` on the user (no foreign key, no backfill, existing rows are `NULL`) and the name is never stored: it
+is read from the current record of that user at read time (`display_name` when set, else `username`), so a rename shows
+at once. When that record is gone the whole object is `null`. It is set by `PUT /v1/user/{id}/role` to the caller (a
+request with the user's current role writes nothing), by invite accept to the inviter (`NULL` when the inviter record is
+missing), and by the ownership transfer: the new Owner is assigned by the former Owner, whose own value becomes `NULL`.
+First-user registration and `POST /v1/role/{id}/reassign` leave it alone. The key is always present on accepted-user
+items of `GET /v1/user` (gate `users.view`, unchanged; assigners are resolved from the users already loaded) and on
+`access` of `GET /v1/auth/me` (own data, one extra lookup at most). Invite items never carry it, and `PublicUser` and the
+login, verify, register and invite-accept bodies do not change.
+
 | Route | Permission | Session only | Purpose |
 | --- | --- | --- | --- |
-| `GET /v1/user` | `users.view` | no | Users and open invites, newest first. A user is `{ id, kind: "user", username, display_name, email, role, status: "accepted", created_at }`; an invite is `{ id, kind: "invite", email, role, status, created_at }`. The roles are read with one `List` call. |
-| `PUT /v1/user/{id}/role` | `users.change_role` | yes | Body `{"role_id": N}` (required). Answers 200 with the user item. |
+| `GET /v1/user` | `users.view` | no | Users and open invites, newest first. A user is `{ id, kind: "user", username, display_name, email, role, role_assigned_by, status: "accepted", created_at }`; an invite is `{ id, kind: "invite", email, role, status, created_at }`. The roles are read with one `List` call. |
+| `PUT /v1/user/{id}/role` | `users.change_role` | yes | Body `{"role_id": N}` (required). Answers 200 with the user item, whose `role_assigned_by` is the caller. |
 | `POST /v1/user/invite` | `users.invite` | no | Body `{"email", "role_id"}`; `role_id` is optional and 0 or absent means the Writer role. Answers 201 `{ id, kind: "invite", email, status, role, created_at, expires_at }`. |
 | `POST /v1/user/invite/{id}/renew` | `users.invite` | no | Renews an expired or pending invite; it keeps its role and the response carries it. |
 | `DELETE /v1/user/invite/{id}` | `users.invite` | no | Cancels an invite (204). No coverage is needed: cancelling removes power. |
@@ -440,6 +451,7 @@ body, target, `confirm_email`, write. Every refusal writes nothing, not even the
 
 | Status | Body | When |
 | --- | --- | --- |
+| 409 | the human message | `POST /v1/user/invite` only. "This address already has an account." carries `X-Error-Code: email_has_account`; "There's already a pending invite for this address." carries `X-Error-Code: invite_pending`. |
 | 400 | `invalid_role` | `role_id` names no role (user change or invite), or the invite's role no longer exists on renew. |
 | 400 | `invalid_transfer` | The transfer target is unknown, yourself, unverified, or not a user (an invite id is never valid). |
 | 400 | `confirmation_mismatch` | `confirm_email` differs from the target's email (exact, case-sensitive match). |