feat(admin): keep server errors where a restart cannot take them

The panel's watcher reported four 5xx today — twice from one address at
11:49, twice from another at 10:45 — and there is no way to find out what
any of them were. verdande logs the real cause of every 500, but on a Rune
the log belongs to the container and the container is replaced on every
restart. So an operator is told that something broke and given nothing to
act on, which is the worst of both: alarming and useless.

Every 500 now writes a row: what the handler was attempting in its own
words, the error it hit, the method and path, who was asking, and the
request id that ties it back to the log line for whoever still has it. The
"what" is the part a status code cannot give — "list projects" and "move
task" are the difference between a fault you can find and one you can only
count.

Written best-effort and never checked. This is the path that is already
reporting a failure, and a diagnostic that can itself fail the request
would turn one broken screen into two.

Threading the request through `internal()` and `storeError()` touched 108
call sites across 19 files, which is the price of not having had it there
from the start. It is mechanical and the compiler checked all of it.

Kept for thirty days by the nightly sweep: long enough to answer "what
happened last week", short enough that a fault loop cannot fill the volume
the tasks live on.

Read at Indstillinger → Fejl, administrators only — it carries paths,
account names and the server's own error strings. The empty state says
"Ingen fejl registreret. Det er den rigtige tilstand", because a blank
panel should not read as a broken one.

The test drops a table and asks for the endpoint that reads it: the same
code path a disk error takes, and the row that comes back has to name the
operation, the account and the request.

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

docs/openapi.yaml

@@ -856,6 +856,60 @@ paths:
         "204": { description: Deleted. }
         "404": { $ref: "#/components/responses/NotFound" }
 
+  /api/v1/errors:
+    get:
+      tags: [auth]
+      summary: What has gone wrong lately. Administrators only.
+      description: |
+        Every 500 the API has answered, newest first, with what the handler was
+        attempting and the error it hit.
+
+        These are written to the database rather than only to the log because the
+        log does not survive. On a Rune the log belongs to the container, and the
+        container is replaced on every restart — so a panel watcher reports "HTTP
+        5xx, twice, at 11:49" long after the line explaining it has gone, which
+        tells an operator that something broke and gives them no way to find out
+        what.
+
+        Kept for thirty days by the nightly sweep: long enough to answer "what
+        happened last week", short enough that a fault loop cannot fill the volume
+        the tasks live on.
+      parameters:
+        - { name: limit, in: query, schema: { type: integer, default: 100, maximum: 500 } }
+      responses:
+        "200":
+          description: OK
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  errors:
+                    type: array
+                    items:
+                      type: object
+                      properties:
+                        id: { type: string }
+                        at: { type: string, format: date-time }
+                        method: { type: string }
+                        path: { type: string }
+                        status: { type: integer }
+                        what:
+                          type: string
+                          description: What the handler was attempting, in its own words.
+                          example: list projects
+                        message: { type: string }
+                        user_name:
+                          type: string
+                          description: |
+                            Who was asking, when there was somebody. A fault only
+                            one account hits is a different problem from one
+                            everybody hits.
+                        request_id:
+                          type: string
+                          description: Ties the row back to the log line, for whoever still has it.
+        "403": { $ref: "#/components/responses/Forbidden" }
+
   /api/v1/users:
     get:
       tags: [auth]