D4 · Workspaces domain: split WorkspaceAdminService into workspace, members, roles, teams, statuses and settings use cases

Added requirement (from the PAR-412 review): when the workspaces facade starts authorising from RequestContext, the effective permissions for a verified user acting through an API key must be the user's role permissions ∩ the key's scope. Today TenantBearerFilter assigns the key's permissions outright (platform / security).

• Fix it here. Add a test where a read-only key used by an admin user can't write, and one where a full key used by a read-only member can't do admin actions.
• Then make PermissionService read from RequestContext instead of ActorContext / KeyContext.

Plan (branch par-417-workspaces, PR to rebuild).

Backend workspaces/{model,persistence,usecase,api,mcp} behind one WorkspacesFacade, copying the labels domain:

• workspace (create/rename/slug/icon/delete/leave), settings (features) and public access (team visibility)
• members (list/role/remove) + invites: email invites (token stored hashed, expiry, role; delivery via outbox kind workspace.invite.email, handler logs/no-ops with a TODO when no mail transport) and invite links (create/revoke/preview/accept)
• roles, teams (public/private), statuses (CRUD/reorder), per-user-per-workspace pins (list/replace), my workspaces (switcher)
• Flyway: invite table, pins table, tenant icon, sentence-case rename of SEEDED default statuses only (exact old names).
• Permission semantics: RequestContext gets a credentialScope; a verified user acting through an API key gets role permissions INTERSECT key scope. WorkspaceAccessService is the single copy of the rule; legacy PermissionService delegates to it, and the workspaces paths no longer touch ActorContext/KeyContext. Tests both ways (read-only key + admin user cannot write; full key + read-only member cannot admin).
• Projects/sprints/shared views stay in a slimmed legacy WorkspaceAdminService (not in this ticket's list; they belong to their own domains). Web domains/workspaces/data/{server,hooks}: settings, teams page, switcher, sidebar teams, members, pins from the API; prune suppressions.

PR open: https://github.com/ParadauxIO/taskl.ie/pull/48 (against rebuild). Workspaces domain behind WorkspacesFacade, permission-intersection fix with tests, V38/V39 migrations, web domain data layer, sidebar teams and server-side pins. ArchUnit store 1928 -> 1716, ESLint suppressions 89 -> 74. Waiting on CI.

Orchestrator review of #48: approved apart from the points below, so I've sent it back.

Must fix: rebase onto rebuild (PAR-414 merged as #47). Expect conflicts in RequestContext (keep both privateTeams and credentialScope), WorkspaceAccessService and AccessStore, and in the issue pages.

Email invites: any signed-in user holding the token can currently accept one.

• If the JWT's verified email is easy to get, check it against the invite's email.
• If not, leave a TODO(PAR-383) and say so in the PR.

Outbox: write a note in the code that delivered workspace.invite.email outbox payloads must be purged when the mail sender lands, because they contain the raw invite token.

Looks good:

• Invite tokens are stored hashed.
• Granting a role is capped by Member.mayGrant.
• The permission rule is user role ∩ key scope, tested both ways.
• The V39 sentence-case rename touches only the seeded names.
• The ratchet went down (ArchUnit store 1928 → 1716).

Merged into rebuild as #48 (bd60ed4) after the rebase onto PAR-414.

• Email invites now require the accepting user's verified email to match the invite's address (case-insensitive). Invite links stay open to anyone who has them.
• A TODO(PAR-383) in InviteEmailHandler notes that outbox payloads must be purged once the mail sender lands, because they contain the raw invite token.

Ratchet compared with rebuild before this merge: ArchUnit store 1865 → 1653, ESLint suppressions 76 → 61. Handoffs to PAR-384 (settings UI) and PAR-383 (onboarding) are in the report above.