The OpenAPI document describes the caller's own routes: profile, SSH keys, pins, assigned and orgs #4845

Intent: a harness can read and keep its person's own things through OpenAPI. Today none of /api/v1/user* is described.

Done:

• [ ] rows for GET/PATCH /api/v1/user, GET/POST /api/v1/user/keys, DELETE /api/v1/user/keys/{id}, GET /api/v1/user/pins, DELETE /api/v1/user/pins/{owner}/{name}, GET /api/v1/user/assigned and GET /api/v1/user/orgs, placed right after the existing GET /api/v1/repos row
• [ ] PUT /api/v1/user/pins/{owner}/{name} is left out until the put method exists (the app-routes OpenAPI issue adds it); say so in the pull
• [ ] the keys rows say which token scope adding and removing need, as the handler checks it

Each row says what the route answers (its shape in the summary), whether it needs a token (auth), its body fields, query and refusals, as the existing rows do. test/openapi.test.ts must still pass (every described route is registered). Add a test asserting each new path and method is in the served document. Another issue adds rows in parallel, so put these exactly where named.