feat: an assignee on the row, and the activity log made visible

Two more things the database has been recording and the interface has
never shown.

**Who a task is waiting on, on the row.** Only when it is not you: your own
list would otherwise carry your own face on every line, which is a column
of one initial telling you nothing. The point of showing an assignee is
that it is somebody else.

That needed names, and a task carries only an `assignee_id`. `GET /people`
is the primitive: everybody you share a project with, plus yourself,
fetched once per session. Not per row, and not per project either — a list
would have to know which project each task belongs to before it could ask
for that project's members. Deliberately *not* the instance's user list,
which is `/users` and administrators only: a task list has no business
enumerating everybody with an account here.

It sits first in the meta line, because who changes what the rest of the
line means — a date on somebody else's task is their deadline, not yours.

**And the activity log.** Nineteen kinds of entry have been written since
the beginning — every project, section, member, task and comment event —
and `GET /projects/{id}/activity` has answered honestly the whole time with
nothing on the other end. There is a Historik panel on the project now,
loaded when it is opened rather than with the page, and the event keys
become Danish in exactly one place. An unknown key falls through to itself
rather than being hidden: a build that records something this table has not
learned should still show that it happened.

One test assertion had to change, and it is worth saying why. It matched
"males inden fredag" against a row whose title is "males inden" — quick add
read "fredag" as the due date — so it was really matching the title
concatenated with the metadata beside it. Putting the assignee between them
broke it. The assertion now names the task's own text.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/openapi.yaml

@@ -1352,6 +1352,36 @@ paths:
                           type: array
                           items: { $ref: "#/components/schemas/Task" }
 
+  /api/v1/people:
+    get:
+      tags: [views]
+      summary: Everybody you share a project with, and yourself.
+      description: |
+        What an interface needs to put a name and a face on an `assignee_id` — in
+        a task row, in a filter, anywhere a person appears beside work. One
+        request per session rather than a lookup per row, and per project members
+        would mean knowing which project every task belongs to first.
+
+        Deliberately not the instance's user list: that is
+        `/users`, administrators only. A task list has no business enumerating
+        everybody with an account here.
+      responses:
+        "200":
+          description: OK
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  people:
+                    type: array
+                    items:
+                      type: object
+                      properties:
+                        id: { type: string }
+                        name: { type: string }
+                        avatar_color: { type: string }
+
   /api/v1/delegated:
     get:
       tags: [views]