fix(#348 review F1-F4): uncache the workspace-restriction gate + int-spec + docs

- F1 [medium — the substantive one]: hasRestrictedPagesInWorkspace is now UNCACHED
  (a plain EXISTS per call, like its sibling hasRestrictedPagesInSpace). Caching it
  (even 5s) reintroduced an access-control leak the space path never had: a
  concurrent whole-workspace read in the insert->commit window of the FIRST
  restricted page could re-populate `false` under withCache (read-then-set, no
  del-during-read guard) and override the insert-time bust, leaking that page to
  unauthorized users for up to the TTL. Uncaching removes both the DB/cache
  asymmetry and the TOCTOU race; the space path already accepts this per-call cost.
  Reverted the now-unnecessary insertPageAccess cache-bust and removed the dead
  HAS_RESTRICTED_PAGES_IN_WORKSPACE cache key.
- F2 [test]: page-permission-workspace-filter.int-spec.ts (real PG) — the
  short-circuit returns the full input set with zero restrictions AND filters out
  the page the user can't reach when a restriction is present (proving the authz
  behavior is unchanged), the 0->1 transition flips immediately, and the flag is
  per-workspace scoped.
- F3 [doc]: documented the deploy-time write-lock in the migration header — the
  non-CONCURRENT GIN trigram builds take a SHARE lock that blocks writes on
  pages/users/… for minutes on a large tenant; run in a maintenance window or
  build CONCURRENTLY out-of-band for big installs.
- F4 [doc]: corrected the jwt.strategy comment — the reused req.raw.workspace is
  the middleware's selectAll superset (not "the exact row this query returns"),
  harmless because AuthWorkspace already preferred that object.

Gate: server tsc 0; the new int-spec 3/3 on real Postgres.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

apps/server/src/database/migrations/20260705T120000-perf-indexes.ts

@@ -32,6 +32,17 @@ import { type Kysely, sql } from 'kysely';
  *      DESC, but only `(page_id, created_at DESC)` exists → extra sort.
  *    - comments: `findPageComments` does WHERE page_id ORDER BY id ASC, but only
  *      `(page_id)` exists → extra sort.
+ *
+ * DEPLOY-TIME LOCK WARNING: these are plain (non-CONCURRENT) CREATE INDEX
+ * statements — CONCURRENTLY is impossible because Kysely runs each migration in a
+ * transaction. They take a SHARE lock that BLOCKS writes (INSERT/UPDATE/DELETE) on
+ * pages/users/groups/comments/page_history for the duration of the build. The two
+ * GIN trigram builds on pages.title / users.name are the slow ones and can take
+ * minutes on a large tenant → a write-outage window during the deploy migration.
+ * For large installations, run this migration in a maintenance window, or build
+ * the trigram indexes out-of-band with CREATE INDEX CONCURRENTLY before deploying
+ * (then this migration's `IF NOT EXISTS` is a no-op). Small/typical tenants are
+ * unaffected.
  */
 export async function up(db: Kysely<any>): Promise<void> {
   // Index-compatible, output-identical redefinition of f_unaccent (see header).