Invites: send and revoke document invites

[Adron]

Part of #57 — Email invites for lists and documents (invite someone who has no account yet)

The document equivalent of the list invite flow, on the existing document access/collaborators
screen.

• POST /api/documents/{id}/invites, GET /api/documents/{id}/invites,
  DELETE /api/documents/{id}/invites/{token}.
• Sits alongside the existing collaborator roles (viewer / editor / admin) rather than replacing
  them.

Tests: send/list/revoke round-trips.

---

Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.

[Adron]

Implemented in #102 (branch issue/59-document-invites). Closing here — review and any follow-up happens on the PR.

Two contract facts that differ from this issue's assumptions, both from /help/api/sharing → Email invites and confirmed live:

• Invite roles are watcher / collaborator / manager, not viewer/editor/admin.
• The 201 from POST .../invites returns no token — only { email, role, expiresAt, url }. The token has to be recovered from the landing URL's last path segment, otherwise you cannot revoke an invite you just sent.
• There is also no status field on a pending invite; the four states the web shows are derived client-side from accepted / expiresAt / revokedAt. And re-inviting the same address is idempotent, so "already invited" is not an error state.

This also uncovered a separate, more serious bug now filed as #101: the existing collaborator flow sends viewer/editor/admin, and POST /api/documents/{id}/collaborators does not validate the role — it silently falls back to watcher. So every collaborator added from Android today is read-only regardless of the role chosen.

#58 (the lists equivalent) can copy this almost verbatim; the PR lists exactly which files and what to mirror.