API: expose membership roles in the login response

[themightychris]

Problem

The companion-API login response (POST /api/v1/auth/login) currently returns only token, user {id, email}, organization_id, and expires_at — nothing about the membership's roles.

With #655 requiring pathways_studio_editor on the selected organization membership for all write endpoints (sync, journal-photo upload), a client has no way to know at login whether the session is effectively read-only. The best available workaround is a capability probe — an empty {"pathways": []} sync POST interpreted as 403-forbidden → read-only vs 200 → writable — which the field companion now ships (JarvusInnovations/pathways-field-companion#96). That works, but it's an extra round trip, needs real version/station ids before it can fire, and infers authorization state instead of reading it.

Request

Include the selected membership's roles in the login response, e.g.:

{
  "data": {
    "token": "…",
    "user": { "id": "…", "email": "…" },
    "organization_id": "…",
    "roles": ["pathways_studio_editor"],
    "expires_at": "…"
  }
}

Notes:

• The companion client already parses an optional roles array when present and falls back to the probe when absent, so this is adoptable without coordination.
• For multi-org users, roles should describe the same membership that organization_id reports (the one AssignApiOrganization selects). If org selection via X-Organization-Id can change the effective membership per-request, a roles field on the 403 org-listing response — or a lightweight GET /me that honors the header — may be a better long-term shape; either satisfies the need.
• Additive and backward-compatible; strict clients that reject unknown fields should be the only compatibility check.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HoGkr6FT6SKZCYDBkNqKBj