fix(permissions): deny space permissions to non-members (invite-bypass)

computePermissions() returned the space @everyone role's permissions without
verifying the caller had joined the space. Because CREATE_INVITE is in
DEFAULT_EVERYONE_PERMISSIONS, any authenticated user could mint an invite code
for a request-only space — whose id is listed by /api/spaces/explore — and then
self-join via /api/spaces/:id/join, bypassing the join-request approval flow.
The same gap let non-members read message history and search default channels.

Root cause:
- computePermissions now returns 0n for non-members (space owner and instance
  admin still short-circuit first, so they are unaffected).

Defense in depth (request-only spaces are approval-gated, never invite-joinable):
- both invite-code join endpoints reject visibility='request' (private stays
  invite-joinable — its only entry path; public too).
- POST /api/spaces/:id/invite refuses to hand out a code for request spaces.
- POST /api/dm/space-invite refuses to card a local request space, checked by
  space id against the local table so a spoofed spaceInstanceOrigin can't slip
  past it.
- InviteModal hides the invite affordances for request spaces.

Also removes the unused computeCategoryPermissions(), which duplicated the
resolution algorithm without the membership gate.

Adds unit + route + component tests covering non-member/member/owner/admin
resolution and the request/private/public visibility matrix.

Reported-by: BadAtCaptchas (#2)

docs/systems/permissions.md

@@ -45,6 +45,15 @@ Storage: Bigint decimal strings in SQLite TEXT columns (bigint not JSON-safe).
 ### Step 1: Owner/Admin Check
 - Space owner OR instance admin (`isAdmin === 1`) → return ALL_PERMISSIONS
 
+### Step 1b: Membership Gate
+- If the user is **not** a member of the space (`getMember` returns nothing) → return `0n`
+- A non-member has no permissions in a space they have not joined. Without this,
+  the @everyone role in Step 2 would leak default member rights (VIEW_CHANNEL,
+  READ_MESSAGE_HISTORY, CREATE_INVITE, …) to any authenticated non-member —
+  allowing them to read channels and mint invite codes for spaces they never
+  joined. Owner and instance admin are already resolved in Step 1, so they are
+  unaffected.
+
 ### Step 2: Compute Base (space-level)
 - Start with @everyone role permissions (role where `id === spaceId`)
 - OR together all permissions from user's assigned roles
@@ -89,7 +98,6 @@ if channelOverride:  base = (base & ~deny) | allow
 | `permissionsToString(perms)` | Bigint → decimal string for JSON |
 | `stringToPermissions(str)` | Decimal string → bigint (supports legacy JSON array format) |
 | `computePermissions(userId, spaceId, channelId?)` | Full resolution algorithm |
-| `computeCategoryPermissions(userId, spaceId, categoryId)` | Stops at category level (no channel overrides) |
 | `hasPermission(userId, spaceId, permission, channelId?)` | Boolean wrapper |
 | `getMember/isMember/isSpaceOwner` | Membership checks |
 | `isDmMember/isBanned` | DM/ban checks |

docs/systems/spaces.md

@@ -113,6 +113,8 @@ Cross-references: [database.md](database.md) (table schemas), [permissions.md](p
 
 **Behavior:** Returns existing `inviteCode` if one exists. Only generates a new one (`crypto.randomBytes(4).toString('hex')`) if the space has no invite code. Invite codes are permanent (no expiration).
 
+**Visibility gate:** returns `403` for `request`-visibility spaces — they are approval-gated and have no usable invite link (the join endpoints reject invite-code joins for them), so the endpoint refuses to hand one out. The client (`InviteModal`) shows an "invite by join request" notice instead of the invite UI for such spaces, and `POST /api/dm/space-invite` likewise rejects a `request`-visibility **local** space with `403 space_requires_approval` (remote request spaces are enforced by their home instance at join time).
+
 **Response:** `{ inviteCode: string }`
 
 ### Invite URL Format
@@ -168,7 +170,9 @@ Two endpoints serve the same purpose:
 | `POST /api/spaces/:id/join` | Join when spaceId is known (body: `{ inviteCode }`) |
 | `POST /api/spaces/join` | Join by code only, spaceId looked up from `inviteCode` |
 
-**Validations:** invite code match, not banned, not already a member.
+**Validations:** invite code match, not banned, not already a member, and **space visibility is not `request`**.
+
+**Visibility gate:** invite-code joins are rejected (`403`) for `request`-visibility spaces — entry to a request-only space must go through `POST /api/spaces/:id/request-join` + manager approval, never a bearer invite code. `private` spaces remain invite-joinable (an invite is their only entry path); `public` spaces are joinable by code or via `POST /api/spaces/:id/public-join`. Combined with the permission membership gate (a non-member cannot obtain `CREATE_INVITE`, see [permissions.md](permissions.md)), this closes the invite-bypass path where a non-member could mint a code for a request-only space and self-join without approval.
 
 **Side effects:**
 1. Insert `space_members` row